Mail Archives: djgpp-workers/1999/04/26/05:13:41
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.
- Raw text -