Re: [Xen-devel] [PATCH 4.4 2/2] libxl: Fix building libxlu_cfg_y.y with bison 3.0

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.01.16 at 11:30, <ian.campbell@xxxxxxxxxx> wrote:
> On Wed, 2016-01-06 at 02:10 -0700, Jan Beulich wrote:
>> > > > On 04.01.16 at 15:50, <ian.jackson@xxxxxxxxxxxxx> wrote:
>> > From: Ed Swierk <eswierk@xxxxxxxxxxxxxxxxxx>
>> > 
>> > - Use %lex-param instead of obsolete YYLEX_PARAM to override lex
>> > scanner
>> >   parameter
>> > - Change deprecated %name-prefix= to %name-prefix
>> > 
>> > Tested against bison 2.4.1 and 3.0.2.
>> > 
>> > This is expected to sometimes (depending on timestamps and whether the
>> > bison input files are edited) break building on systems with ancient
>> > versions of bison.  Bison 2.4.1 is known to work and was released in
>> > December 2008.
>> > 
>> > Also, consquentially, regenerate bison output files with bison
>> > 1:2.5.dfsg-2.1 from Debian wheezy.
>> > 
>> > Signed-off-by: Ed Swierk <eswierk@xxxxxxxxxxxxxxxxxx>
>> > Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
>> > Tested-by: Wei Liu <wei.liu2@xxxxxxxxxx>
>> > Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
>> > Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
>> > 
>> > (cherry picked from commit 7ba4cdfadd4f3c45d65ffe50e621759f458fedc0)
>> > 
>> > [ I have checked that rebuilding the bison and flex input produces no
>> >   further changes. -iwj ]
>> > 
>> > Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
>> 
>> Well, as indicated already when the original change went in, a
>> statement of compatibility back to a bison released in 2008 is
>> fine, but not really sufficient considering that e.g. compiler and
>> and binutils are permitted to older. I stopped objecting to the
>> change for -unstable at that time, but I'm not sure we want to
>> introduce such an incompatibility (the %name-prefix change)
>> with older bison in a wrap-up release. In the end the question
>> certainly is whether updating the build host distro for released
>> branches is a proper thing to do.
> 
> The outputs are checked in, which mitigates things somewhat since you
> wouldn't expect bison to actually be run unless you had edited the input
> files.
> 
> I suspect that in reality it is run needlessly in some cases, I'd say we
> should either fix that (might be hard, since it involves VCS setting 
> timestamps consistently) or at least provide a manual "never run bison" 
> switch.

But that's again something we may well do on -unstable, but I'd
be hesitant to backport such to (almost) retired branches.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel