Date:	Mon, 26 Apr 1999 13:11:16 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Andris Pavenis <pavenis AT lanet DOT lv>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: v2.03: wrapping up
In-Reply-To:	<B0000084852@stargate.astr.lu.lv>
Message-ID:	<Pine.SUN.3.91.990426130631.22711B-100000@is>
MIME-Version:	1.0
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

On Mon, 26 Apr 1999, Andris Pavenis wrote:

> Let's imagine that upcomming egcs-1.2 will need modified version of lib/specs
> (I think it's very likely). Of course we can put it in gcc binary archive, but user 
> may run in problems if he upgrades libc after installing gcc.

I'm not saying that specs shouldn't come with the compiler.  I don't have 
anything against specs being part of the compiler distribution.  I only 
want a clean and reliable solution for __DJGPP__ and __DJGPP_MINOR__ to 
be defined according to the library in use.  That is all that worries me.

> I see one serious problem with that:
> 	I can have another version of DJGPP (lib and include directories only)
> 	located somewhere else (eg. current CVS version with different version
> 	number).

So let's have the compiler look at %C_INCLUDE_PATH% instead of 
%DJDIR/include%.  Does this solve the problem?

> Forcing to get minor version
> number from include files which is not included automatically perhaps will cause
> some problems mostly for developers. But I still think that these are temporary
> problems and we should go through them.

I don't see why do you think these problems will ever go away.

- Raw text -