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 X-Sender: broeker AT acp3bf To: djgpp-workers AT delorie DOT com cc: Zippo Workers Subject: Re: ANNOUNCE: Bison 1.28 ported to DJGPP In-Reply-To: <38BA7CD5.F4268EAA@softhome.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.