Re: fixincludes needed on linux?

[Zack Weinberg <zack at rabi dot columbia dot edu>]

On Wed, 21 Oct 1998 17:42:07 +1000, David Dawes wrote:
>On Mon, Oct 19, 1998 at 08:21:21AM -0400, Zack Weinberg wrote:
>>On Mon, 19 Oct 1998 18:37:24 +1000, David Dawes wrote:
>>>On Fri, Oct 16, 1998 at 09:32:16AM -0700, Bruce Korb wrote:
>>>
>>>>> >> X11 headers are notoriously ugly.  You want to take this up with the
>>>>> >> Xfree86 people.
>>>>> >
>>>>> >Have you an e-addr handy?
>>>>>
>>>>> No, but look at http://www.xfree86.org/.
>>>>
>>>>XFree86@XFree86.org.Attached, again, are file diffs for files containing 'X
>11
>>>' in
>>>>their name.
>>>
>>>Those X header changes on their own will cause problems on some platforms.
>>>We would need a more portable (or more complete) solution.
>>
>>I thought so.  The changes as you saw them are not intended for
>>general consumption.  They are the output of gcc's `fixincludes'
>>program which corrects problems with the system headers on a
>>particular installation.
>>
>>The problem gcc has with X11 headers is just that they use e.g.
>>#ifdef unix instead of #ifdef __unix__; the names without __ are not
>>defined in ANSI mode.  I believe if you change it to e.g.
>>#if defined unix || defined __unix__ throughout that gcc will be
>>happy.
>
>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 ?

>>Long term you might want to specialize those headers at build time but
>>this is probably more work than you want to deal with.
>
>I don't know about doing that.  We do want to make everything more
>ANSI-compliant, but without breaking too much in the process.

One possible approach is to move all the machine-specific #ifdefs into Xmd.h
(in some cases, defining feature-switch symbols that the other headers look
for) and make sure everything includes that -- which is necessary anyway,
right?  Then only one header depends on these things.  Then you can think
about generating Xmd.h at build time and having it just define the feature
switches directly.

zw