Re: GCC headers and DJGPP port

[Eli Zaretskii <eliz at delorie dot com>]

> Date: Fri, 21 Jul 2000 17:26:47 +0200
> From: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
> 
> I can understand that there is additional contents in your limits.h. I
> fail to see what this has to do with GCC installing its own copy of
> limits.h into a gcc directory. It is common in GCC installations to
> have multiple copies of limits.h, and chain them together with
> #include_next. This works very well on other GCC ports (e.g. Linux,
> Solaris) - why doesn't it work on DJGPP?

#include_next does work, but it requires various #ifdef's to protect
it from multiple redefinitions, and these #ifdef's introduce special
reserved symbols that make maintenance harder.  Where this is
necessary, it is done, but we would like to make the number of such
headers as small as possible.

I think if we discuss each of the headers that GCC currently installs,
we could come to a reasonable compromise as to what can go and what
needs to stay.

> Forcing GCC not to install certain headers does not minimize
> problems.

It does minimize the potential for a new GCC version to break existing
code due to incompatible definitions in the headers distributed with
GCC.

> Instead, if a new feature in GCC requires support in header
> files, your port would break as your libraries would not provide that
> support.

This is a different problem, one which we are more willing to risk
having.  If a new feature cannot be used until the library is
upgraded, that's semi-okay, since that new feature didn't exist
previously.  But if a new release of the compiler breaks code which
worked before that, that is a much more serious problem.