Date: Mon, 26 Apr 1999 12:11:24 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Andris Pavenis cc: DJ Delorie , 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 Mon, 26 Apr 1999, Andris Pavenis wrote: > I think where __DJGPP_MINOR__ is needed one should include stdio.h or > sys/version.h. Sorry, the more I think about this solution, the less I like it. It introduces a subtle dependence on the order in which headers are included. A naive user won't expect the order of inclusion to be important; an experienced user will have hard time to debug such problems, and will probably be infuriated to find out the reason. This solution is a maintainer's nightmare. For example, most GNU packages include config.h *before* any other header files (because config.h says #define HAVE_UNISTD_H etc.). Do I now need to revisit all the version-specific solutions that I devised over the years and try to figure out whether they might now break and whether I need to include stdio.h to solve that? sys/version.h is a non-solution for application code, since using it will break the port if it is compiled with versions before 2.02. (And yes, old versions are still supported; Emacs even supports v1.x to this day.) Since it depends on specific headers to be included, this solution is simply too fragile; when it does break, it will cause subtle bugs and mysterious behavior that will take a lot of effort to find and debug. If we will be lucky, during compilation some compiler error will pop up about some missing functionality; if we are less lucky, the code will mysteriously break at run time, because some fragment condintioned upon __DJGPP_MINOR__ didn't get compiled. Please, PLEASE let's not adopt this ``solution''! When this issue was discussed about a year ago, I suggested an alternative solution. All we need is a transparent way for the compiler to add "-imacros %DJDIR%/include/sys/version.h" to the switches passed to the preprocessor. This is all it takes to make the version-specific symbols to be defined seamlessly and reliably. I could think about two ways of making this happen: 1) add DJGPP-specific code to gcc to do this (after all, it already expands %DJDIR%); 2) invent a new specs magic to expand an environment variable, and use that in the specs file to add -imacros to the cpp section. I think the second way is better, since it defines a general-purpose feature that we could use in the future for similar problems, and it might be more welcome by maintainers and users on other platforms. But even the first alternative is much, much better than to rely on stdio.h to be included. It is IMHO highly unfortunate that during all the time that passed since that discussion, nobody has done anything to solve this problem in the new ports of the compiler. I suggest that we do that now, instead of relying on header inclusion.