Date: Sun, 23 Jul 2000 07:05:14 -0400 (EDT) Message-Id: <200007231105.HAA13293@indy.delorie.com> From: Eli Zaretskii 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 Precedence: bulk > From: Mike Stump > 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.