Date:	Sun, 23 Jul 2000 07:05:14 -0400 (EDT)
Message-Id:	<200007231105.HAA13293@indy.delorie.com>
From:	Eli Zaretskii <eliz AT delorie DOT com>
To:	mrs AT windriver DOT com
CC:	djgpp-workers AT delorie DOT com, gcc AT gcc DOT gnu DOT org,
	martin AT loewis DOT home DOT cs DOT tu-berlin DOT de
In-reply-to:	<200007222219.PAA01604@kankakee.wrs.com> (message from Mike Stump
	on Sat, 22 Jul 2000 15:19:20 -0700 (PDT))
Subject:	Re: GCC headers and DJGPP port
References:	<200007222219 DOT PAA01604 AT kankakee DOT wrs DOT com>
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> From: Mike Stump <mrs AT windriver DOT com>
> Date: Sat, 22 Jul 2000 15:19:20 -0700 (PDT)
> 
> > If it's okay with you, I'd like to discuss limits.h (and syslimits.h
> > that is related to it) first.  Why is it necessary for GCC to install
> > its own version of this header?
> 
> Wrong question.  I'll answer it anyway, because it is best.  It is
> best, because gcc already knows so much about the target system, that
> it can generate this file.

Nevertheless, I think that system headers are much more closely
related to the library than to the compiler.  Where the compiler needs
something special in the headers to make sure it generates correct
code, it is indeed justified to use compiler-supplied definitions.
But is limits.h such a case, and if so, which part of it,
specifically?

> A way of approaching this, would be to explain to me the problem this
> causes, slowly, so that I can understand the issues, and we can work
> out a solution to the problems encountered.

Our problem with installing GCC headers is that this complicates our
maintenance.  It introduces an additional dependency between GCC
development and DJGPP library development.  Each change in GCC's
headers will potentially require changes in either the library or the
other system headers.  Likewise, changes in system headers or the
library which clash with GCC's headers would be impossible or hard,
even if the conflicts do not indicate real problems.  Use of special
redefinition guards (whose names must be coordinated with GCC's
headers), #include_next, etc.--all this introduces extra complexity
into library maintenance.

Given the scarcity of our resources, we would like to prevent this
friction as much as possible.  We would like to avoid the need for
library maintainers to be aware of all the intricacies of the headers
which come with GCC, including any changes scheduled for the next
release.  The infrequent releases and the nature of our users (see
below) dictate that.

Another dimension of the problem is user support.  The support
provided on comp.os.msdos.djgpp for solving installation and usage
problems is very efficient; most questions are answered within hours,
the rest within a day or two.  This is imperative when dealing with
the kind of clueless newbies that most of our users are--DJGPP is the
first development environment for many of them.

This support quality doesn't come without an effort.  Given that the
ported GCC is distributed as precompiled binaries, making its setup on
any given machine, in any directory, seamless and reliable is not
easy.  It took years of incremental improvements to get where we are
today: you unzip the files, set a single environment variable, and all
the ported packages (not only GCC) start working.

But installation snafus still happen, albeit at a low rate; when they
do, we, the maintainers, need to understand what went wrong in order
to get the user back on track.  Interdependencies between header
files, the critical role of `specs', various add-on packages people
install which come with their own headers--all these already make this
task not easy at all.  Add to this GCC-supplied headers, which might
or might not be installed into the right place, and the user support
becomes much harder.  We would like to avoid that.

- Raw text -