Mail Archives: djgpp-workers/2000/07/21/14:12:44
> Date: Fri, 21 Jul 2000 17:26:47 +0200
> From: "Martin v. Loewis" <martin AT loewis DOT home DOT cs DOT tu-berlin DOT 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.
- Raw text -