RE: libxl dirty in tree after libxl build

[Paul Durrant <xadimgnik@xxxxxxxxx>]

> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of Ian 
> Jackson
> Sent: 12 June 2020 15:12
> To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
> Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>; Wei Liu <wl@xxxxxxx>
> Subject: Re: libxl dirty in tree after libxl build
> 
> Andrew Cooper writes ("libxl dirty in tree after libxl build"):
> > A build of libxl has just dirtied the tree with:
> >
> > index 05f7ac74a0..94a4438666 100644
> > --- a/tools/libxl/libxlu_disk_l.c
> > +++ b/tools/libxl/libxlu_disk_l.c
> > @@ -10,221 +10,11 @@
> >  #define FLEX_SCANNER
> >  #define YY_FLEX_MAJOR_VERSION 2
> >  #define YY_FLEX_MINOR_VERSION 6
> > -#define YY_FLEX_SUBMINOR_VERSION 4
> > +#define YY_FLEX_SUBMINOR_VERSION 1
> >  #if YY_FLEX_SUBMINOR_VERSION > 0
> >  #define FLEX_BETA
> >  #endif
> >
> > and a whole slew of other changes in the generated code.  It looks like
> > the version of Flex has just been updated in Jessie.
> >
> > Given the flex and bison are strictly required for the libxl build, why
> > is this temporary file checked in?
> 
> The point of the exercise is to *not* require them.  The reason is
> that some of our developers have very old development systems which do
> not support essential flex/bison features.

Can't we check in a file with a different name 'e.g.' with something like 
'.tmpl' on the end, which we copy into place in case the
flex/bison don't generate such a file? That way the checked in file never gets 
dirtied.

  Paul

> 
> How about we update them to the version from buster ?
> 
> Ian.