| Summary: | Including orb.idl when using non-standard extensions | ||
|---|---|---|---|
| Product: | TAO | Reporter: | fp |
| Component: | IDL Compiler | Assignee: | DOC Center Support List (internal) <tao-support> |
| Status: | ASSIGNED --- | ||
| Severity: | normal | CC: | fp |
| Priority: | P3 | ||
| Version: | 1.4.2 | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: | Patch to include <tao/orbC.h> and <tao/orbS.h> when the IDL file includes <orb.idl> | ||
|
Description
fp
2004-09-28 10:41:02 CDT
Created attachment 284 [details]
Patch to include <tao/orbC.h> and <tao/orbS.h> when the IDL file includes <orb.idl>
Looks like your fix will work for your problem, but the general problem goes a lot wider and deeper than that. Here are a few other use cases: Components.idl: Similar to orb.idl, but for components - must be included by any IDL file that contains a component or eventtype declaration. We would have to do a 2nd string compare for this like you have proposed for orb.idl. tao/xxxSeq.pidl: If an application uses one or two sequences of basic types, the developer may want to just include these files individually instead of pulling them all in with orb.idl. It would be too much over head to do string compares for all of these. tao/Policy.pidl: If a developer wants to extend the CORBA policy framework for an application, this would have to be included. There are many other such IDL files in TAO that might be included for similar reasons. orbsvcs/orbsvcs/CosNaming.idl: or any of the other CORBA services. It is actually quite a common use case for an application to include one of the CORBA services IDL files. Even recompiling the library with the file extension option will not work, since many source files in the library already include generated files with the default extension. It would be possible to add an option to the IDL compiler to suppress the propagation of the file extension to generated include filenames, but that would still require users to organize their IDL files to separate system IDL file includes from application IDL file includes, and the creation of at least one dummy IDL file just to hole includes of other IDL files. It doesn't seem that this solution is workable for you, but if it is, let me know. >
> It would be possible to add an option to the IDL compiler to suppress the
> propagation of the file extension to generated include filenames, but that
> would still require users to organize their IDL files to separate system IDL
> file includes from application IDL file includes
>
This path seems messy.
IMHO, including <orb.idl> is much better than selectively including any of its
sub-PIDL files (such as your Policy.pidl example). It's portable across ORBs.
No code is generated for the extraneous #included files, so it's not a footprint
issue, the only tradeoff is against compile time.
Is a compile-time tradeoff worth so much complexity? I don't think so. PCH
capable compilers prefer a single, massive include file anyway. Based on this
admittedly extreme rationale, I would just dump everything that is currently
in <orb.idl> into its equivalent, <tao/corba.h>, and have all client-side
header files pull it in. This change might be too controversial for you.
Still, that wouldn't address the other files you mentioned.
A moderate measure would be to have the IDL compiler recognize TAO's common
directory prefixes, <tao/...> and <orbsvcs/...>, and use the default file
extensions for that.
I admit, including one of the .pidl files is not a common use case, but we have a good number of users who want absolute minimum footprint, both on disk and runtime, and would object to being forced to pull in everything from orb.idl to get one IDL file. Including corba.h is not exactly controversial ;-), but we did move in exactly the opposite direction about a year ago. That had been the standard include generated by the IDL compiler for years, but last summer we made the IDL compiler more fine-grained about what it generates for includes. corba.h is now kept around only for backward compatibility - users can include it in their code by hand if required by legacy or if it suits their needs. I'm not sure how trying to recognize standard path prefixes would work in all cases. One of these files might be included using only a local filename, with a -I option passed from the IDL compiler to the preprocessor (the IDL compiler uses the C++ preprocessor of the platform it is run on). I have a feeling that complete path information might sometimes reside only in the preprocessor, and be out of reach of IDL compiler source code. I have run into this problem with CosNaming.idl and CosLifeCycle.idl Just a thought - Iona Orbix addresses this issue by supporting an IDL pragma (IT_SystemSpecification). This pragma is present in all the IDL that comes with the Orbix distro and instructs the IDL compiler to apply special treatment to the included file, i.e. generate standard suffixes for include filenames etc.. Maybe something similar could be considered for TAO. At present I have just added an IDL postprocessing step to my makefile when processing my own IDL - this regenerates the stubs and skeletons using a make variable containing a recognised list of standard OMG interface names.. |