help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mesa-dev] Mesa (master): glsl: do not use deprecated bison-keyword


From: Erik Faye-Lund
Subject: Re: [Mesa-dev] Mesa (master): glsl: do not use deprecated bison-keyword
Date: Thu, 23 May 2019 10:48:46 +0200
User-agent: Evolution 3.32.1-2

On Wed, 2019-05-22 at 18:06 +0200, Akim Demaille wrote:
> Hi Erik,
> 
> > Le 22 mai 2019 à 08:54, Erik Faye-Lund <
> > address@hidden> a écrit :
> > 
> > I ended up reverting the change [from-%error-verbose to %define
> > parse.error verbose] , and I can't find an obcious way to
> > support both old and new versions with the same source file.
> 
> Well, you just disable warnings about deprecated features.
> -Wno-deprecated.
> 
> > The Android SDK also ships a pre-3.x version of Bison, so you're
> > not
> > the only one affected. Also, Chocolatey doesn't provide a new
> > enough
> > version of Bison for Windows either.
> 
> I would be interested in knowing why some distros lag.  Do you
> happen to know why for some of them?
> 

The only clear examples I know of are the Android SDK and Chocolatey.
As I said before, we mighit not have to use the bison version shipped
in the Android SDK, so perhaps that's fixable. And for Chocolatey, it
turns out they have a winflexbison pacakge and a winflexbison3 package,
and the latter has a more recent Bison version.

So looking at this again, it looks like it might be solveable, at least
in the cases where this is visible to me.

Brian: do you think VMWare cuold upgrade the Bison version used in the
forseeable future?

> > The problem is that Bison doesn't seem to have any mechanism for
> > doing
> > statements like these conditionally.
> 
> We try to keep your sources nice and clean, and using %if or
> things like this is anything but nice.  So far these old
> directives are not a maintenance burden, so there is no plan
> to drop support for them.  But still, at least for consistency,
> I promote the newest forms.
> 

Thanks for that clarification, makes sense.

> > The only way around that that I
> > can see is to pre-process the source files somehow. But especially
> > with
> > three different build systems, that's not really a venue I find
> > particularly attractive. If someone can think of a neat solution, I
> > would certainly love to hear about it :)
> 
> Don't do that!
> 

Yeah, I'm not planning on going down that road, as it seems needlessly
convoluted.

> > For now I guess we can just live with the warning. But whenever the
> > Bison devs decide to remove support for %error-verbose, I fear that
> > we'll either have to drop support for older versions or live with
> > pre-
> > processing.
> 
> This should not happen.  What should happen though, is that distros
> stop shipping old versions.
> 

I fully agree.

> [generating the parsers in the tarballs]
> > I don't really think this would work for us in Mesa. We no longer
> > generate the distribution using autotools since we switched to
> > Meson,
> > we just do git archive these days.
> 
> Well, I think that's a pity.  The distinction between end user tools
> and maintainer tools is a useful one.  As exemplified by the issue
> at hand.
> 

I don't think this would have solved the issue for VCS users anyway,
which is a large portion of our users these days, so I'm not sure it
would have helped all that much.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]