Date:	Wed, 21 Jan 1998 15:00:02 +0100 (MET)
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
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.LNX.3.93.980121144836.2863J-100000@acp3bf>
MIME-Version:	1.0

On Tue, 20 Jan 1998, DJ Delorie wrote:

> >   I would prefer this technique, but how to include the changes
> >   for djggp.env in the gcc280b.zip? In the readme? Knowing
> >   that there are people which cannot read them?
> 
> 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

Goodness, looks like we're on our way to re-inventing the Windows
.ini file or even the Win95 registry. Instead of adding this code
to crt1, what about this method:

*) Each package comes with its own set of entries for the DJGPP.ENV
   file, with djdev carrying the basic setup. These fragments could
   be stored in %DJDIR%/env/{package name}.

*) Create a program that merges all those fragments and builds the
   actual %DJDIR%/djgpp.env file. Problematic cases, like two packages
   trying to modify the same [section] of the file, and maybe
   even the same variable, could be forwarded to the user for
   decision.

This would mean less code bloat in crt1, and still allow packages to
modify DJGPP.ENV without the risk of 'Joe Average User' damaging it.  We'd
just have to add a note in a prominent place that 'you have to run
"envmerge" after you unzip one or more new of the distributed .zip's'. Yet
another thing our trusty FAQ askers will probably manage to do wrong, but
it should work. 

Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -