Mail Archives: djgpp-workers/2002/02/20/03:25:54
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 -