Date: Tue, 27 Apr 1999 13:36:11 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Andris Pavenis cc: djgpp-workers AT delorie DOT com Subject: Re: v2.03: wrapping up In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Tue, 27 Apr 1999, Andris Pavenis wrote: > > That's what I suggested a year ago when this problem was discussed in > > the context of GCC 2.8.x. I think using "-imacros" to include > > sys/version.h will solve this cleanly and reliably. > > I don't think so. Imagine if somebody will want to test something with > DJGPP-2.00 or 2.01 which didn't have sys/version.h. I don't see how this will cause any trouble: gcc from those old versions won't use the (yet unknown) way of passing -imacros to the preprocessor, so cpp won't see -imacros. Those old versions will use lib/specs from the old DJGPP distributions, which define __DJGPP__ and __DJGPP_MINOR__. So I don't think old versions will have any problems with this. > lib/specs). I haven't met any problems with it. Yesterday I tried to look > at sources of emacs-19.34 and didn't find any problems when building it. > Grepping sources also shows that all should be Ok. I don't understand why do you say ``all should be Ok''. In the Emacs 19.34 distribution, the files src/msdos.c and src/dosfns.c check whether __DJGPP_MINOR__ is 0 (for some bugs in v2.0). Current Emacs 20.3 sources check for 2.02 or later (for some features missing in v2.01, like sigprocmask). This is not limited to Emacs, either. For example, the sources for dvilj program (from the TeX/Web2c distribution) check for v2.02 or later, to work around a problem in earlier stubs with inherited file handles; the next version of Make will check for v2.02 as well, because we now have sys_siglist[] and psignal. And this is only off the top of my head. The problem is real, believe me. > I myself haven't seen any problems. Binaries of DJGPP port of egcs-1.1.2 > does not define DJGPP_MINOR in specs. Therefore it would be easy to test > this with this version. It is not easy at all to test this. How do you test whether anything is broken in large and complex programs like Make or Emacs? Most probably, you won't see any trouble until you create some very special situation; and to do that, you need a thorough understanding what exactly do those #ifdef's try to solve and under what conditions are these solutions needed, and then analyze the source files and the headers they include to see if maybe they include stdio.h at the right time. Alternatively, you need to remember what were the problems which caused that special code to be written, and how to recreate those problems. I don't know how much time will it take me to recall the problems I solved years ago. Like I said: it's a maintainer's nightmare. Is it really that hard to add a few lines to GCC so that it expands %C_INCLUDE_PATH% and passes -imacros to cpp? Maybe we should do that instead of arguing.