X-Authentication-Warning:	delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Subject:	Re: bison and djgpp.env
From:	Tim Van Holder <tim DOT van DOT holder AT pandora DOT be>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc:	djgpp-workers AT delorie DOT com,
	Juan Manuel Guerrero
	<ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De>
In-Reply-To:	<Pine.SUN.3.91.1020220093921.21448M-100000@is>
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 1020220093921 DOT 21448M-100000 AT is>
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

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.

- Raw text -