Please report new issues athttps://github.com/DOCGroup
A project of ours, for reasons too complicated to explain, requires the use of a particular naming scheme for IDL-generated files. So I am using the appropriate tao_idl command-line options, and all is well -- until one of our IDL files #includes <orb.idl>. That file already receives some special treatment in DRV_get_orb_idl_includes() (driver/drv_preproc.cpp); thus all files that <orb.idl> itself includes -- such as <tao/AnySeq.pidl> -- will be included by the original IDL file, i.e., the one that included <orb.idl>. Now - this is where it breaks: when compiling an IDL file that includes orb.idl, using non-standard extensions, e.g., "tao_idl -hc _fuzz.h foo.idl", the generated header file will also try to #include TAO's files using this extension. I.e., the generated foo_fuzz.h will try to include <tao/AnySeq_fuzz.h>. I have patched the IDL compiler to output #include <tao/orbC.h> in the client header, and #include <tao/orbS.h> in the server header, whenever <orb.idl> is encountered as an include file. I then created both files to just include the relevant headers. To me, this seems more straightforward than the existing treatment of orb.idl.
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..