X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f Subject: Re: bison and djgpp.env From: Tim Van Holder To: Eli Zaretskii Cc: djgpp-workers AT delorie DOT com, Juan Manuel Guerrero In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 20 Feb 2002 09:21:43 +0100 Message-Id: <1014193306.14698.21.camel@bender.falconsoft.be> Mime-Version: 1.0 Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Wed, 2002-02-20 at 08:43, Eli Zaretskii wrote: > > On 20 Feb 2002, Tim Van Holder wrote: > > > I think this has been discussed before, but I couldn't find it in the > > archives: do we still want to support really old bison versions (i.e. > > those that need BISON_HAIRY and BISON_SIMPLE to be set) in 2.04? > > I think we do want to support them. People shouldn't be required to > update all of their binaries together with djdev. > > What harm does it make to continue having these variables? Juan was > talking about a test suite, and adding the `+' solves that. I think > that's good enough, and we shouldn't be unreasonably radical. The problem is that it points to a wrong path ($DJDIR/lib instead of $DJDIR/share/bison) - a basic difference between bison 1.28 and later. > Also note that the v2.03 refresh will have those changes, so it's not > only v2.04 that we need to consider. > > > I believe 2.04 should ditch the variables altogether (and bison's README > > should probably tell users to remove old skeletons from $DJDIR/lib to > > avoid problems). > > Why does it make sense to break back compatibility, unless we have a very > good reason? The point is that bison now uses pkgdatadir (i.e. share/bison, not lib) as target location for its support files. So someone building a recent bison, would get a non-functional bison, unless they either actively override the default settings for BISON_{HAIRY,SIMPLE} djgpp.env provides, or place the new skeletons in the old, deprecated, location. Neither solution is particularly palatable to me; bison should be in control of where it looks for its skeleton files. The environment variables are there for the _user_, not the system, to override the built-in defaults. The only reason we have these variables in djgpp.env in the first place is because pre-2.03 apps had hardcoded paths (using the build system's DJDIR as $prefix). Since 2.03's /dev/env support, this is no longer needed. I agree that people don't need to update everything, but I do feel it's reasonable to require them to have to use a 2.03-based bison (i.e. with /dev/env support), regardless of whether that's 1.28 or 1.32+ (all versions inbetween were very buggy, and probably shouldn't be on simtel). So backward compatibility is only an issue if you want pre-2.03 binaries to work as before.