Message ID | 1451919024-7904-2-git-send-email-ian.jackson@eu.citrix.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
>>> On 04.01.16 at 15:50, <ian.jackson@eu.citrix.com> wrote: > From: Ed Swierk <eswierk@skyportsystems.com> > > - 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@skyportsystems.com> > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> > Tested-by: Wei Liu <wei.liu2@citrix.com> > Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> > Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > > (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@eu.citrix.com> 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. Jan
On Wed, 2016-01-06 at 02:10 -0700, Jan Beulich wrote: > > > > On 04.01.16 at 15:50, <ian.jackson@eu.citrix.com> wrote: > > From: Ed Swierk <eswierk@skyportsystems.com> > > > > - 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@skyportsystems.com> > > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> > > Tested-by: Wei Liu <wei.liu2@citrix.com> > > Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> > > Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > > > > (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@eu.citrix.com> > > 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. Ian.
>>> On 06.01.16 at 11:30, <ian.campbell@citrix.com> wrote: > On Wed, 2016-01-06 at 02:10 -0700, Jan Beulich wrote: >> > > > On 04.01.16 at 15:50, <ian.jackson@eu.citrix.com> wrote: >> > From: Ed Swierk <eswierk@skyportsystems.com> >> > >> > - 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@skyportsystems.com> >> > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> >> > Tested-by: Wei Liu <wei.liu2@citrix.com> >> > Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> >> > Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> >> > >> > (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@eu.citrix.com> >> >> 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
diff --git a/tools/libxl/libxlu_cfg_y.c b/tools/libxl/libxlu_cfg_y.c index 4437e05..07b5a1d 100644 --- a/tools/libxl/libxlu_cfg_y.c +++ b/tools/libxl/libxlu_cfg_y.c @@ -76,7 +76,7 @@ /* Line 268 of yacc.c */ #line 19 "libxlu_cfg_y.y" -#define YYLEX_PARAM ctx->scanner +#define ctx_scanner ctx->scanner #include "libxlu_cfg_i.h" #include "libxlu_cfg_l.h" @@ -656,7 +656,7 @@ while (YYID (0)) #ifdef YYLEX_PARAM # define YYLEX yylex (&yylval, &yylloc, YYLEX_PARAM) #else -# define YYLEX yylex (&yylval, &yylloc, scanner) +# define YYLEX yylex (&yylval, &yylloc, ctx_scanner) #endif /* Enable debugging if requested. */ diff --git a/tools/libxl/libxlu_cfg_y.y b/tools/libxl/libxlu_cfg_y.y index aa9f787..5acd438 100644 --- a/tools/libxl/libxlu_cfg_y.y +++ b/tools/libxl/libxlu_cfg_y.y @@ -17,7 +17,7 @@ */ %{ -#define YYLEX_PARAM ctx->scanner +#define ctx_scanner ctx->scanner #include "libxlu_cfg_i.h" #include "libxlu_cfg_l.h" %} @@ -31,9 +31,9 @@ %pure-parser %defines %error-verbose -%name-prefix="xlu__cfg_yy" +%name-prefix "xlu__cfg_yy" %parse-param { CfgParseContext *ctx } -%lex-param { void *scanner } +%lex-param { ctx_scanner } %token <string> IDENT STRING NUMBER NEWLINE %type <string> atom