Mail Archives: djgpp-workers/2001/09/13/11:18:22
On Thu, 13 Sep 2001, Juan Manuel Guerrero wrote:
> The canonical place to install the parser files is %DJDIR%/share/bison and
> IMHO djgpp's bison port should follow this.
Yes, I agree. The issue is how to make the transition without hurting
users.
> On Thu, 2 Mar 2000, Eli Zaretskii wrote:
> > On Tue, 29 Feb 2000, Mark E. wrote:
> >
> > Bison's defaults work just fine, so why not get rid of the bison section in djgpp.env?
> >
> > Some people might still have an old port of Bison. However, we could
> > indeed safely assume that by the time v2.04 is out, they will all
> > switch ;-).
> >
> > Thanks!
>
> There is no ofending intention here. I know that everybody forgets what he
> has said years ago.
I didn't forget: note that the same issue worries me now as it was 1.5
years ago ;-) That issue is compatibility with old ports of Bison.
What was discussed in the thread you cited was different fromthe issue I
rasied now. Mark asked whether it was okay to modify djgpp.env for
v2.04, and I thought it was okay, because the latest Bison binary
distributions install the parsers in share, which is where Bison looks
for them.
By contrast, the issue I raised now is different: is it okay to drop
lib/bison.* files from the binary distribution, while we still have DJGPP
v2.03 as the official version, where djgpp.env still points to lib/bison.*
If a user upgrades to v2.04 (when it's available), she won't need to do
anything, provided she has Bison 1.28 or Bison 1.29 installed. By
contrast, if a user upgrades now to Bison 1.29, she _must_ edit
djgpp.env, or else Bison will become broken (and _subtly_ broken on top
of that).
> After reading the mails in the worker list I have assumed
> that the bison specific entries in djgpp.env would be removed in 2.04.
They are not removed yet in the current CVS, but that's not what worries
me. I was talking about people who upgrade to the latest Bison now.
> To clarify the issue: I have submitted patches for djgpp build-in support
> to Akim D. This port works with exactely those patches. This implies that if
> the port behaviour is not welcome at all or considered brocken, then the
> build-in support for future bison versions is also brocken and new patches
> must be submitted to the GNU mantainer.
Since you already uploaded the binaries, I'd suggest to wait and see.
Perhaps the problem doesn't exist after all.
Btw, the names in the binary package are bison.hairy and bison.simple,
not bison.hai and bison.sim. This means that on LFN platforms, if a user
upgrades from bsn128b.zip, they will have both share/bison.hai and
share/bison.hairy. That might confuse someone. bsn129b.dsm could have
taken care of that, but it doesn't...
- Raw text -