Re: [XEN PATCH] tools: Have flex and bison mandatory

[Elliott Mitchell <ehem+xen@xxxxxxx>]

On Tue, Feb 07, 2023 at 10:48:56AM -0800, Elliott Mitchell wrote:
> On Tue, Feb 07, 2023 at 06:02:45PM +0000, Anthony PERARD wrote:
> > On Tue, Feb 07, 2023 at 06:03:12PM +0100, Jan Beulich wrote:
> > > On 07.02.2023 17:09, Anthony PERARD wrote:
> > > > This also remove the way the missing binaries are been handled, with
> > > > double-column-rules, which might be an issue sometime.
> > > 
> > > These double-colon rules should never have been introduced. Double
> > > colons have a different meaning ("terminal rule") for pattern rules.
> > > In fact they were my initial suspects when looking into that odd build
> > > failure in CI.
> > 
> > After some more investigation, I don't think anymore the double-colon
> > rules here is an issue.
> > 
> > I think the issue that Andrew saw in the CI with "libxlu_cfg_y.o"
> > failing to build while "libxlu_cfg_l.[ch]" are been regenerated is
> > probably because make doesn't consider "libxlu_cfg_l.[ch]" as a group of
> > targets.
> > 
> > If for some reason we have:
> >     libxlu_cfg_l.h newer than libxlu_cfg_l.l newer than libxlu_cfg_l.c
> > 
> > Then make seems to take two parallel decision:
> >     When building libxlu_cfg_y.o:
> >         libxlu_cfg_l.h is newer than libxlu_cfg_l.l
> >         -> libxlu_cfg_l.h is up-to-date, start building libxlu_cfg_y.o
> >     When building libxlu_cfg_l.o:
> >         libxlu_cfg_l.c is older than libxlu_cfg_l.l
> >         -> we need to generate libxlu_cfg_l.c first
> > Then, libxlu_cfg_y.o fails to build because libxlu_cfg_l.h is been
> > updated do to the parallel build of libxlu_cfg_l.o.
> > 
> > I can easily reproduce the issue with:
> >     touch libxlu_cfg_l.c; sleep .1; touch libxlu_cfg_l.l; sleep .1;
> >     touch libxlu_cfg_l.h; sleep .1; make -j
> > And having "sleep 1" in "%.c %.h: %.l" recipe, between `rm` and `flex`.
> > 
> > I don't know how to properly fix this yet.
> > Event writing "%.c %.h &: %.l" doesn't work, with make 4.3, which is
> > supposed to be grouped targets. But that's is maybe fixed in 4.4.
> 
> Might this be solved with:
> 
> %.c: %.l | %.h
> 
> I'm unsure whether order-only dependencies are GNU-make only (there is a
> good chance).  There is also the option of using .PRECIOUS

Then upon more reading wouldn't:

%_y.c: | %_l.c

Accomplish the job?  (assuming GNU-make or everyone has copied that
feature)


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@xxxxxxx  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445