X-Authentication-Warning: acaxp6.physik.rwth-aachen.de: broeker owned process doing -bs Date: Fri, 25 Feb 2000 04:09:44 +0100 (MET) From: Hans-Bernhard Broeker To: djgpp-workers AT delorie DOT com Subject: Re: ANNOUNCE: Bison 1.28 ported to DJGPP In-Reply-To: <200002242322.SAA31756@delorie.com> 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 Thu, 24 Feb 2000, Mark E. wrote: > > 2. Some of the files in the binary distribution are long > > (e.g. REFERENCES), but others, like bison.sim and bison.inf, are > > truncated. Why? > > bison.sim needs to work in both environments. But for that, you don't have to shorten the name! As long as the name is 'bison.simple' in all places that refer to it, and also the actual file is named with that full LFN name, in the .zip file, things will automagically work (by truncation on non-LFN systems). Assuming the user followed the general DJGPP unzipping instructions, that is. > > the old files, why is it a good idea to disable the environment > > variables BISON_SIMPLE and BISON_HAIRY? This makes DJGPP the only [...] > But djgpp.env doesn't let the user control them anyway so it's already out of > their hands. Well, it's a whole lot easier for users to edit their DJGPP.ENV, if they're properly instructed, than to rebuild BISON each time they need a different skeleton file, isn't it? I agree with Eli that this was a bad idea: you've moved this even farther out of users' hands than it already was. If at all, you might put instructions containing a corrected [bison] section for djgpp.env into your README.DOS file, instead of disabling this environment influence completely. This is one point where the design limitations of djgpp.env show through: a package cannot automatically modify its own djgpp.env sections, selectively, without the risk of breaking the user's own personalizations. > > All this just to correct the decision made years ago to put the > > files into the lib subdirectory (because share didn't yet exist)? > > Well, mistakes do deserv be corrected, yes? Sure, but not if the correction breaks documented features of the original package you're porting (obeyance of the BISON_SIMPLE environment variable, in the case at hand), on the other end. Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.