Mail Archives: djgpp-workers/2002/02/20/04:11:29
On 20 Feb 2002, Tim Van Holder wrote:
> 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.
This was discussed with Juan, and I believe we have it solved without
hurting backwards compatibility.
> 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.
I believe the latter alternative is what Juan does in the ported package.
> 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.
It's okay for newer versions of Bison not to look at these variables, or
to look inside /dev/env/DJDIR/share first. But older ports should
continue to work with newer djdev releases, IMHO.
> 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 don't agree that it's reasonable. Users could have their reasons for
not upgrading, and we shouldn't second-guess them.
- Raw text -