Mail Archives: djgpp-workers/1999/04/27/07:53:23
On 27 Apr 99, at 13:36, Eli Zaretskii wrote:
> > 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).
It took some minutes for me to grep sources and see that stdio.h is included
before using __DJGPP_MINOR__ in these both files so we have correct definition of
__DJGPP_MINOR__. (I touched sources of EMACS for DJGPP first time at all). That is why
I said all is Ok. Not only because I built EMACS-19.34.
> 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;
I suggest following way of testing:
grep sources to find where DJGPP_MINOR is used
add
#if defined(__DJGPP__) && !defined(__DJGPP_MINOR__)
#error DJGPP_MINOR is not defined
#endif
before using this macro
And we'll get places where we have problems. I think currently such check could even stay
in released sources.
> 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.
If we're not trying to find reasonable way of testing
> 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.
At first CPP from ports gcc-2.8.X or egcs knows where to find standard include
file directories even without %C_INCLUDE_PATH%. So expanding
%C_INCLUDE_PATH% maybe not enough.
Also I don't like that way. I don't like to introduce similar things.
Andris
- Raw text -