Re: fixincludes needed on linux?

[Bruce Korb <korb at data-design dot com>]

Zack Weinberg wrote:

> >Understood, but some of the changed symbols were defined explicitly
> >by X's imake config.  For example, it adds -Dsun to the compiler
> >arguments rather than relying on the compiler to define it.  The X code
> >knows this.  SunPro's C compiler defines "__sun" in ANSI mode and both
> >"sun" and "__sun" otherwise (similarly it defines __unix instead of
> >__unix__).  The imake config could be changed to define __sun__, but
> >then anyone who has X code which relies on the old behaviour will have
> >problems.
>
> In that case perhaps GCC should avoid modifying the X headers in this
> fashion.  Bruce, can you get fixincludes to ignore X11/*.h ?

I can do anything.  :)  Would such a change in fixincludes behavior be
acceptedinto EGCS?   Different question. Remember, we are talking about compiling
some
random program that is being compiled by EGCS and including an X11 header.
When X11 is itself being compiled, it is free to do the "-Dsun" thing.
EGCS will not predefine "sun".

Here are the  issues, as I see them.

1.  No matter what gets decided about what to do with non-conforming headers
    (fix them in the original; or fix them in the compiler internal includes;
    or just ignore them), the preprocessor must present to the compiler
    the correct text for the machine/os target being compiled to.
    And it must do so for the currently installed base of header files.

2.  It is not required, but it would be nice to minimize the number of files
    ensnared by fixincludes with inconsequential changes.  For example,
    there is not much point in ANSI-fying "#if defined(sun)" on a i386 Linux
    box.  On a _sun_ box, however, EGCS/GCC only pre-defines "__sun__".
    Consequently, in order to deliver the correct text to the compiler,
    fixincludes _must_ change solitary "#if defined(sun)" constructs.

Given that #1 is not subject to change and that EGCS will not predefine
non-ANSI pre-defines, the questions are:

A.  Should X11 change their headers so that they are not ensnared with
    innocuous fixincludes changes?  E.g. replace "defined(sun)" with
    "defined(sun) || defined(__sun__)".

B.  Should fixincludes be changed so that it makes fewer changes that have
    no effect on the compile?  E.g.  ignore "sun" on non-Sun boxes and
    ignore "sun" when "__sun__" is also present.

At the moment, what is being installed is, to the best of my ability, an
exact, faithful copy of the old fixincludes functionality.  Once that dust
settles, we can worry about enhancing fixes in ways that do not break
things where the fixes are truely needed.  I must say, tho, that I think
it would be really nice if the suppliers of the headers would, when reasonably
convenient, make slight changes to their code.  Changes so that not only
would any real broken-ness be corrected, but even leave clues in them to
let fixincludes be able to determine that a fix is not needed.

I think we are turning this new stuff on soon now, yes Jeff?