Date: Wed, 21 Jan 1998 15:41:43 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: DJ Delorie <dj AT delorie DOT com>
cc: robert DOT hoehne AT gmx DOT net, djgpp-workers AT delorie DOT com
Subject: Re: gcc 2.8.0
In-Reply-To: <199801210111.UAA22405@delorie.com>
Message-ID: <Pine.SUN.3.91.980121154110.27671F-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Tue, 20 Jan 1998, DJ Delorie wrote:

> One thing I was thinking of adding to crt1 is the ability to have a
> *file* named after the executable, like djgpp/envs/gcc, so that the
> env file can be included in the zip file instead of in djgpp.env

Or you could have a special directive in DJGPP.ENV that causes the
startup to read a named file in the same syntax as DJGPP.ENV.  For
example:

	[gcc]
	%%include %DJDIR%/gcc.env

However, I don't see how this feature makes updating older packages
much easier.  It only solves the problem of those who edit their
DJGPP.ENV and don't want those edits to be overwritten by a package
they unzip.  But I don't think it does anything to allow multiple
versions of the same package to co-exist peacefully on the same
machine.  That's why GNU have chosen to have the version part of the
path name.

You could, of course, say, e.g. this in DJGPP.ENV:

	[gcc]
	%%include %DJDIR%/%GCC-VERSION%/gcc.env

and then change the version with a flip of a single variable in the
environment.

> I'd prefer using djdev's specs, which use djdev's stubify, so that if
> you install a new djdev, you get the new stub when you compile.

I think the issue of the stub coded inside Binutils vs the one in
`stubify' should be resolved, before we can really claim that core
DJGPP and GCC/Binutils are independent of each other.  The fact that
the new Binutils can read the stub using an environment variable is a
step in the right direction, but I don't think we should expect too
many people to set up environment variables.