Re: [basic-improvements, committed] Split tm.h from config.h

[Zack Weinberg <zack at codesourcery dot com>]

Fergus Henderson <fjh@cs.mu.OZ.AU> writes:

> On 30-Nov-2002, Zack Weinberg <zack@codesourcery.com> wrote:
>> 
>> The changes to treelang, fixinc, and several Make-lang.in files, are a
>> bit more invasive than strictly necessary.
>
> Does that mean you made a non-backwards-compatible change to the GCC
> front-end interface?  <Sigh>
>
> You know, it would really nice if one day the GCC front-end interface
> was actually stable.

Yes, this is an incompatible change.  We have never made any assertion
that the front-end interface was stable.  You choose to maintain a
front end outside the official repository, which means you have to
take the burden of keeping up with these changes.

We are working on cleaning up the front end interface so that it has
some degree of sensical design to it.  Once that is done we can think
about maybe stabilizing it.  I'd estimate another two or three major
releases before the question comes up.

>>     If you include system headers directly in source files that are
>>     components of GCC you are probably doing something wrong.  It is
>>     system.h's responsibility to include most of these for you.  Only
>>     include system headers if you have verified that system.h does
>>     not.  The same goes for headers provided by libiberty.
>
> This is a very fragile and non-extensible design.  It makes it impossible
> to use third-party libraries in a GCC front-end, since the header files
> for those third party libraries may in turn include system header files.

Not true.  You just include the third-party library headers after
system.h.

It really is necessary to let system.h handle this stuff.  As an
example, treelang source files directly included string.h.  That file
doesn't even exist on systems with pre-C89 libraries.  system.h does
an elaborate dance to get it right:

#ifdef STRING_WITH_STRINGS
# include <string.h>
# include <strings.h>
#else
# ifdef HAVE_STRING_H
#  include <string.h>
# else
#  ifdef HAVE_STRINGS_H
#   include <strings.h>
#  endif
# endif
#endif

>>     Unless there is a special need to do otherwise (and I am not
>>     presently aware of any such), config.h and system.h should always
>>     be the first two headers included in source files that are
>>     components of GCC.
>
> For the Mercury front-end, the Mercury header files which define global
> register variables need to be included first, otherwise gcc will report
> an error, because system.h include system header files that define inline
> functions, and all global register variable definitions need to be
> included before any function definitions.

Well, there's your special need.  But I would encourage you to create
a header containing just those global register declarations, and
include only that header before system.h (not before config.h).

It is possible that that constraint is obsolete with the tree-based
inliner.  Anyone know?

>> 	* treelang/lex.l: Move "%{" below copyright notice;
>
> Hmm, does that mean that the copyright notice doesn't get copied to
> the generated lex.c file?  Is that a good idea?

This change was for consistency with all the other such files.

zw