Message-ID: <B0000085627@stargate.astr.lu.lv>
From: "Andris Pavenis" <pavenis AT lanet DOT lv>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Date: Mon, 3 May 1999 13:49:21 +0300
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: v2.03: wrapping up
CC: DJ Delorie <dj AT delorie DOT com>, djgpp-workers AT delorie DOT com
References: <Pine DOT A41 DOT 4 DOT 05 DOT 9905031202260 DOT 37912-100000 AT ieva01 DOT lanet DOT lv>
In-reply-to: <Pine.SUN.3.91.990503131226.18068C-100000@is>
X-mailer: Pegasus Mail for Win32 (v3.02b14)
Reply-To: djgpp-workers AT delorie DOT com

On 3 May 99, at 13:27, Eli Zaretskii wrote:

> 
> On Mon, 3 May 1999, Andris Pavenis wrote:
> 
> > *cpp:
> > %{posix:-D_POSIX_SOURCE} -imacros %s../include/sys/version.h
> 
> Thanks.  (To what directory does %s expand, btw)?

It searches the same patch as for specs file or similar things. Therefore I needed
../include/...

 %s     current argument is the name of a library or startup file of some sort.
        Search for that file in a standard list of directories
	and substitute the full name found.

> I didn't know about this feature (I still use gcc 2.7.2.1).  

Cannot test with gcc-2.7.2.1 as I don't have sources and gcc.exe from gcc-2.7.2.1

> If nobody is
> opposed to it, can we arrange for new binary uploads of GCC 2.8.1 and EGCS
> with specs files modified like above, when v2.03 is released? 
> 
> > Perhaps better would be to copy include/sys/version.h 
> > as lib/djgpp.ver and use '-imacros %sdjgpp.ver' instead.
> 
> I like the include/sys/version.h better, since it will work with 2.8.1
> as well with no changes.
> 
> > 	will break old versions of DJGPP:
> > 		include/sys/version.h - all before 2.02 (we can do it 
> > 			immediatelly as it works with DJGPP-2.02)
> > 		lib/djgpp.ver - all before current if we'll use it
> 
> I only see a problem if somebody installs a compiler with a specs file 
> that includes -imacros and uses that compiler with the library from v2.01 
> or earlier. 
> 
> To solve these cases (which I expect to be rare once v2.03 is released), 
> we could tell people to rename/delete the specs file that goes with 
> the compiler.  They cannot avoid doing that, since otherwise cpp will 
> complain about a missing sys/version.h.
> 
> Older compiler distributions didn't have specs, and would therefore use 
> the lib/specs file from djdev.
> 

We should not have lib/specs. We may have some file with different name which
can be renamed back to specs in lib if user really needs it. 

Andris