Message-ID: <3A2A4FD7.FD144615@softhome.net>
Date: Sun, 03 Dec 2000 14:51:19 +0100
From: Laurynas Biveinis <lauras AT softhome DOT net>
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: lt,en
MIME-Version: 1.0
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC: djgpp-workers AT delorie DOT com
Subject: Re: Patch: make GCC & DJGPP headers compatible
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1001203131752 DOT 2851B-100000 AT is>
Content-Type: text/plain; charset=iso-8859-4
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

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