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

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



On Tue, Dec 09, 2014 at 03:25:29PM +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: Fix building 
> libxlu_cfg_y.y with bison 3.0"):
> > There was a point in time where the prevailing version of bison (or
> > maybe flex) in stable distro releases had a bug which meant these files
> > could not be regenerated easily on common distros. I don't recall the
> > details well enough to know if that time has now passed. Perhaps Ian J
> > does.
> 
> We use (essential) features found only in non-ancient versions of
> bison and flex.  The last time it was proposed to remove these
> pregenerated files, there were complaints from people who were using
> six-year-old bison and flex.
> 
> I think we should prioritise compatibility with new versions of bison
> and flex, and retain the pregenerated versions of people with
> incompatibly old version.
> 
> I think for 4.5 we should:
> 
>  * Regenerate the flex files with current wheezy's flex.  (I have
>    reviewed the diff in the generated code.  It produces trivial
>    changes which add declarations of xlu__cfg_yyget_column and
>    xlu__cfg_yyset_column, but no code body changes - see below.)
> 
>  * Take the patch from Ed and regenerate the bison files too.
> 
> 
> Konrad: can we have two freeze exceptions please ?
> 
> Risk analysis for Ed's patch:
> 
> Not taking the patch hurts systems with bison 2.7.1 or later:
> 
>   - Affected systems include Debian jessie, which will be
>     released during the lifetime of 4.5.

My understanding is that Jessie won't be using Xen 4.5 but Xen 4.4 And the
next version of Debian that will be released will be most likely using Xen 4.6.

However, this issue (building) would even show up in Xen 4.4 - but
I hadn't seen any Debian bugs about this?

> 
>   - Bison 2.7.1 was released in April 2013, a year and
>     a half ago.  So any system which is less than 18 months out of
>     date suffers pain from not updating.

Aye. Any other distro that will use Xen 4.5 that is new (Fedora 21
ships with 3.0.2) can hit this when building the RPMs or out of
tree.

> 
> Taking the patch hurts systems with old bison:
> 
>   - Bison 2.4.1 is known to work and was released in December 2008.
>     So systems which suffer pain from updating are using at least
>     4-year-old bison.

I am not following that. Are you saying that taking this patch will
break building of the sources when using bison 2.4.1 (like Fedora
Core 13 - which is what I use for my small regression testing vehicles).

That would imply an regression?
> 
>   - I have not investigated whether there are even older bison
>     versions which are still OK with updating.

Anything older than Fedora Core 13 is so ancient I would be scared
to run on contemporary hardware.
> 
> On the affected systems:
> 
>   - Attempts to build actually-from-source, or with modified
>     bison input, will definitely fail.
> 
>   - Some proportion of other builds will fail anyway due to
>     timestamp skew.
> 
> 
> Risk analysis for regenerating with current wheezy's flex:
> 
> There doesn't seem to be any actual change in the generated code apart
> from a few new function declarations and changes to #line directives.
> So the risk of breakage is small.  Furthermore:
> 
> Not taking the patch now means that our flex file will be out of date
> and may be regenerated and updated accidentally (or need to be
> regenerated) at some point in the future.  That means that (a)
> whatever risk of breakage we are taking might be discovered at an
> inconvenient time (b) additional build system trouble might result
> from an out of date file.
> 
> 
> There isn't AFAICT a necessary connection between these two but we
> normally regenerate both the bison and flex files together, if
> necessary, before making any changes to the input files.
> 
> Thanks,
> Ian.
> 
> 
> 
> diff --git a/tools/libxl/libxlu_cfg_l.c b/tools/libxl/libxlu_cfg_l.c
> index df352aa..450863a 100644
> --- a/tools/libxl/libxlu_cfg_l.c
> +++ b/tools/libxl/libxlu_cfg_l.c
> @@ -610,6 +610,10 @@ int xlu__cfg_yyget_lineno (yyscan_t yyscanner );
>  
>  void xlu__cfg_yyset_lineno (int line_number ,yyscan_t yyscanner );
>  
> +int xlu__cfg_yyget_column  (yyscan_t yyscanner );
> +
> +void xlu__cfg_yyset_column (int column_no ,yyscan_t yyscanner );
> +
>  YYSTYPE * xlu__cfg_yyget_lval (yyscan_t yyscanner );
>  
>  void xlu__cfg_yyset_lval (YYSTYPE * yylval_param ,yyscan_t yyscanner );
> @@ -762,7 +766,7 @@ YY_DECL
>  #line 53 "libxlu_cfg_l.l"
>  
>  
> -#line 766 "libxlu_cfg_l.c"
> +#line 770 "libxlu_cfg_l.c"
>  
>      yylval = yylval_param;
>  
> @@ -971,7 +975,7 @@ YY_RULE_SETUP
>  #line 104 "libxlu_cfg_l.l"
>  YY_FATAL_ERROR( "flex scanner jammed" );
>       YY_BREAK
> -#line 975 "libxlu_cfg_l.c"
> +#line 979 "libxlu_cfg_l.c"
>  case YY_STATE_EOF(INITIAL):
>  case YY_STATE_EOF(lexerr):
>       yyterminate();
> diff --git a/tools/libxl/libxlu_cfg_l.h b/tools/libxl/libxlu_cfg_l.h
> index 4078302..151064e 100644
> --- a/tools/libxl/libxlu_cfg_l.h
> +++ b/tools/libxl/libxlu_cfg_l.h
> @@ -276,6 +276,10 @@ int xlu__cfg_yyget_lineno (yyscan_t yyscanner );
>  
>  void xlu__cfg_yyset_lineno (int line_number ,yyscan_t yyscanner );
>  
> +int xlu__cfg_yyget_column  (yyscan_t yyscanner );
> +
> +void xlu__cfg_yyset_column (int column_no ,yyscan_t yyscanner );
> +
>  YYSTYPE * xlu__cfg_yyget_lval (yyscan_t yyscanner );
>  
>  void xlu__cfg_yyset_lval (YYSTYPE * yylval_param ,yyscan_t yyscanner );
> @@ -352,6 +356,6 @@ extern int xlu__cfg_yylex \
>  
>  #line 104 "libxlu_cfg_l.l"
>  
> -#line 356 "libxlu_cfg_l.h"
> +#line 360 "libxlu_cfg_l.h"
>  #undef xlu__cfg_yyIN_HEADER
>  #endif /* xlu__cfg_yyHEADER_H */
> diff --git a/tools/libxl/libxlu_disk_l.c b/tools/libxl/libxlu_disk_l.c
> index 2c6e8e3..beea7f9 100644
> --- a/tools/libxl/libxlu_disk_l.c
> +++ b/tools/libxl/libxlu_disk_l.c
> @@ -1011,6 +1011,10 @@ int xlu__disk_yyget_lineno (yyscan_t yyscanner );
>  
>  void xlu__disk_yyset_lineno (int line_number ,yyscan_t yyscanner );
>  
> +int xlu__disk_yyget_column  (yyscan_t yyscanner );
> +
> +void xlu__disk_yyset_column (int column_no ,yyscan_t yyscanner );
> +
>  /* Macros after this point can all be overridden by user definitions in
>   * section 1.
>   */
> @@ -1155,7 +1159,7 @@ YY_DECL
>  
>   /*----- the scanner rules which do the parsing -----*/
>  
> -#line 1159 "libxlu_disk_l.c"
> +#line 1163 "libxlu_disk_l.c"
>  
>       if ( !yyg->yy_init )
>               {
> @@ -1498,7 +1502,7 @@ YY_RULE_SETUP
>  #line 259 "libxlu_disk_l.l"
>  YY_FATAL_ERROR( "flex scanner jammed" );
>       YY_BREAK
> -#line 1502 "libxlu_disk_l.c"
> +#line 1506 "libxlu_disk_l.c"
>                       case YY_STATE_EOF(INITIAL):
>                       case YY_STATE_EOF(LEXERR):
>                               yyterminate();
> diff --git a/tools/libxl/libxlu_disk_l.h b/tools/libxl/libxlu_disk_l.h
> index 08f60e5..f615582 100644
> --- a/tools/libxl/libxlu_disk_l.h
> +++ b/tools/libxl/libxlu_disk_l.h
> @@ -280,6 +280,10 @@ int xlu__disk_yyget_lineno (yyscan_t yyscanner );
>  
>  void xlu__disk_yyset_lineno (int line_number ,yyscan_t yyscanner );
>  
> +int xlu__disk_yyget_column  (yyscan_t yyscanner );
> +
> +void xlu__disk_yyset_column (int column_no ,yyscan_t yyscanner );
> +
>  /* Macros after this point can all be overridden by user definitions in
>   * section 1.
>   */
> @@ -346,6 +350,6 @@ extern int xlu__disk_yylex (yyscan_t yyscanner);
>  
>  #line 259 "libxlu_disk_l.l"
>  
> -#line 350 "libxlu_disk_l.h"
> +#line 354 "libxlu_disk_l.h"
>  #undef xlu__disk_yyIN_HEADER
>  #endif /* xlu__disk_yyHEADER_H */

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.