X-Authentication-Warning:	acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date:	Mon, 28 Feb 2000 15:09:23 +0100 (MET)
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender:	broeker AT acp3bf
To:	djgpp-workers AT delorie DOT com
cc:	Zippo Workers <zippo-workers AT onelist DOT com>
Subject:	Re: ANNOUNCE: Bison 1.28 ported to DJGPP
In-Reply-To:	<38BA7CD5.F4268EAA@softhome.net>
Message-ID:	<Pine.LNX.4.10.10002281502030.9152-100000@acp3bf>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	dj-admin AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Mon, 28 Feb 2000, Laurynas Biveinis wrote:

> I suggest do it as follows: each package provides its own part of
> configuration file, and on every installation/deinstallation the
> main djgpp.env should be concatenated from all those parts.

Either that, or we introduce a two-level system: The central djgpp.env is
kept as is, providing usable defaults for every program. But we could add
a directory (%DJDIR%/envfiles or so) of files called, in the example case,
'bison.env', which would override the settings in djgpp.env, if they
exist. The drawback would be that the code that currently reads djgpp.env
would become more complicated, introducing possible new bugs to a very
sensitive central part of the system. It has the advantage that we
wouldn't have to force everyone to use zippo: directly unzipping packages
would still work.

Or, even simpler to work with, turn djgpp.env into a directory, each of
the sections like [bison] into a separate file 'bison.env', and the
toplevel part into %DJDIR%/djgpp.env/djgpp. This would require a total
rewrite of the code reading djgpp.env, and break backward compatibility,
of course :-(

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

- Raw text -