![]() |
xpidl for CodeWarriorv1.0d1 - first development releaseInstallation Notesxpidl for CodeWarrior consists of three tools, which must be installed in three distinct locations in your "CodeWarrior Plugins" folder:
Setting up an IDL ProjectCreate a new IDL ProjectAfter installing the tools, create a new empty project. Add .idl files for the particular module you are working with (for example all of the .idl files in mozilla/xpcom/idl). Generating HeadersOpen CodeWarrior's target specific settings window. Go to the "Target Settings" panel, and change the "Target Name:" field to "headers". Set the "Linker:" preference to "None". Switch to the "xpidl Settings" panel and set the "Mode:" to "Header Files". The panel should look like the following: ![]() Generating Type LibrariesCreate another target in the IDL project you created before. Call this target "typelibs". Set the "Linker:" preference to "xpt Linker". Go to the "xpidl Settings" panel again, and set the "Mode:" to "Type Libraries". Set the "Linker output:" field to an appropriate name (e.g. "xpcom.xpt"). The xpt Linker will combine all of the .xpt files generated for each .idl file into a single type library. The panel should look like the following: ![]() Sample IDL ProjectA sample project can be found in the Mozilla tree at "mozilla/xpcom/tools/xpidl/macbuild/test". This project points at the current idl files in "mozilla/xpcom/idl". v1.0d2 - second development releaseEnhancementsBetter Dependency TrackingWhen the xpidl compiler generates header or typelib files, it now informs the CodeWarrior IDE that an external file has been created. This lets CodeWarrior know that the external file depends on the .idl file from which it was compiled. Thus, if a header or typelib file is deleted (e.g. you throw away your dist folder), the IDE will correctly recompile the .idl file to regenerate the appropriate file. Moreover, if you're working with an IDL project, and use the "Remove Objects" command, the IDE will delete the external files, giving you a clean slate. The .xpt files are also built within a target specific folder within the IDL project's data folder. Only the final linked .xpt file will appear in the project's output directory. Bug FixesFixed a bug where the linker would always relink the output .xpt library. Fixed a major problem with trapping calls to exit(), causing infinite recursion. Was using exception handling which evidently doesn't work with this kind of shared library setup. Switched to trapping calls to exit() with setjmp/longjmp, and disabled exception handling (for now). v1.0d3 - third development releaseNo new featuresBug FixesEach #include of a .idl file was leaking a file handle. Now, when an include file is done being processed, the file is explicitly closed. v1.0d4 - fourth development releaseNew Feature: Header Alias CreationThe linker has been enhanced to create aliases to header files in the project's output directory. This lets our build system throw away the contents of mozilla/dist, without causing all of the header files to be regenerated, which will speed up dependency builds. To use this feature, you must turn on the linker in your project's header file target, and provide a name of a file for the linker to create in the output directory. For example, if your project is called "moduleIDL.mcp", and you create a type library called "module.xpt", you should call this file "module.headers". This file is only created to provide a timestamp for the Metrowerks IDE. If you throw away the file, the linker will recreate all of the aliases, but the original header files will be untouched. Bug FixesAll of the latest changes to the xpidl compiler have been incorporated in this release. Take a look at the CVS logs to see what changed.
Last Modified on 18 May 1999 by Patrick C. Beard <beard@netscape.com> |
|||||||
| Copyright © 1998-1999 The Mozilla Organization. | |||||||