Re: make --shuffle

[Bruno Haible]

Hi Santiago,

> El 2/12/24 a las 11:25, Bruno Haible escribió:
> >> In file included from ./log.c:24:
> >> ./gettextP.h:71:11: fatal error: libgnuintl.h: No such file or directory
> >>      71 | # include "libgnuintl.h"
> >>         |           ^~~~~~~~~~~~~~
> >>
> >> Full log here:
> >>
> >> https://people.debian.org/~sanvila/make-shuffle/build-logs/gettext_0.22.5-2_amd64-20241030T065521.940Z

What I see there:

In file included from ./log.c:24:
./gettextP.h:71:11: fatal error: libgnuintl.h: No such file or directory
   71 | # include "libgnuintl.h"
      |           ^~~~~~~~~~~~~~
compilation terminated.
make[8]: *** [Makefile:2595: log.lo] Error 1 shuffle=1033553424

indicates an error in the compilation of log.c for the target log.lo;
this is consistent. But when you look at the Makefile.am and the Automake-
generated Makefile.in you see:
  - There is only one rule that creates libgnuintl.h, namely the
    target 'libgnuintl.h'.
  - There is a dependency line
     log.lo:              ../config.h $(srcdir)/gettextP.h libgnuintl.h 
$(srcdir)/gmo.h $(srcdir)/loadinfo.h

So, it appears that the Makefile has the correct dependencies, and
nevertheless the "make --shuffle" process has started executing the log.lo
rule before the libgnuintl.h rule was finished.

> In this case, for example, the relevant question would be:
> 
> How do we ensure that libgnuintl.h exists before trying to use it?

Yup, that's a relevant question, and I think you will have to search
for the bug in the GNU make sources.

> There is something which may help here: Whenever make --shuffle is used,
> it chooses a random seed which makes the failure (when it happens) to be
> reproducible with the same seed. The seed appears in the build log.
> 
> Would that kind of 100% reproducible failures (with a given seed) be more
> likely to be investigated by GNU than a purely random failure?

Certainly, yes. As shown above, you should direct the bug report to the GNU
make team.

> Does this mean that the GNU project would probably try to investigate
> a build failure when it happens 100% of the time on a system with a
> single CPU and without using make --shuffle?

If it happens without option -j: Absolutely, yes.

If it happens only in parallel builds: Sometimes the cost of investigation
is too high, and the maintainers will prefer to add a
.NOTPARALLEL:
line.

> The problem is that it's a complex package and I still don't know if this
> is an upstream bug, or maybe the maintainer is using the code in a way
> which was not expected to be supported, so I'm still undecided about
> what to do...

What is wrong with saying "We routinely build all packages with -j4.
Your package sometimes fails to build in this setting. Please add missing
dependencies and don't rename built files after-the-fact, or add a
.NOTPARALLEL:  line, to let our builds succeed anyway." ?

Bruno