On Thu, 8 May 2003, Bruce Korb wrote:
> > The disadvantage of this solution is that one cannot cause standard headers
> > to include a different header from the one it normally includes by adding -I
> > switches (e.g. for debugging or other special purposes) but this can be
> > achieved by other means; e.g. by using a modified copy of the include
> > hierarchy, by conditionally including headers, or, perhaps, by using macro
> > expanded include directives. In any case, this application should have far
> > less weight than the problem of imposing on the user's header file
> > namespace.
>
> "This application" happens to be GCC. One of the more fun aspects
> of the thing is having to adapt to implementation header files that
> were designed for the native compiler. As such, they are a bit sloppy
> with their syntax, generally. GCC fixes the issue not by shipping
> all the header files it will need for every platform, but instead by
> auto-editing the supplied header. Currently, system headers all
> include each other mostly with <...> constructs. Were you to convince
> implementations to do all the cross-including with "..." constructs,
> GCC would then be forced to clone the essentially entire include
> hierarchy, instead of the few files at present. The real problem comes
> in when the implementation is upgraded/patched and new system headers
> get installed.
How do the auto-edited copies get updated when the implementation is
upgraded? Can you not use the same mechanism for the others (which would
just appear to have had a null auto-edit applied to them)? Alternatively,
you could use symbolic links for the headers that don't need fixing.
--
Ben Harris
Unix Support, University of Cambridge Computing Service.
|