Mail Archives: djgpp-workers/2000/12/03/07:51:59
Eli Zaretskii wrote:
> Sigh... My understanding was that somehow, fixincludes _eliminates_ the
> need for patching our headers. That's why I bothered to make fixincludes
> work for DJGPP. Was that a waste of time?
You have ported the engine of fixincludes, but there are no DJGPP-specific
fixes and generic fixes do not catch them. It should be possible to
implement my patch with fixincludes, but I suggest fixing them here,
because otherwise we might run into problems with binary distributions:
suppose DJGPP binaries of GCC 3.1 comes out earlier than djdev 2.05 and
contains fixincluded headers of 2.04. And then comes out 2.05 and what
should it do with headers? Leave old, but working with GCC, or install
new, but not working?
That's why I suggest to fix our headers. Furthermore, we could even
write DJGPP fixes for fixincludes, so GCC 3.0 could be built with
2.03 or earlier.
> Isn't it correct that headers fixed by fixincludes are installed in the
> GCC's include directory? If so, any fixing that our headers need will be
> done when fixincludes runs.
Yes.
> And since fixincludes only found two
> marginal problems with our headers, I thought we don't need to change
> anything important (those marginal problems can be postponed until v2.04).
This simply means that nobody has written DJGPP specific fixes for fixincludes.
> > Well, I disagree. They aren't mad enough to change _our_ size_t definitions
> > in djgpp.h. They can break DJGPP port in zillions of other ways, but not this
> > one.
>
> They can break what you done by changing the name or the semantics of the
> _SIZE_T macros.
Very, very unlikely. It won't break just DJGPP, it will break everything.
GCC developers don't make changes like this every other Monday.
> However, if I'm the only one who cares, and the others feel comfortable
> with this change, feel free to disregard me and commit the changes.
I won't do that unless you or DJ approve it.
Laurynas
- Raw text -