Re: make --shuffle

[Santiago Vila]

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
>
> I infer from
>    - 
> https://www.gnu.org/software/make/manual/html_node/Options-Summary.html#index-_002d_002dshuffle
>    - https://trofi.github.io/posts/238-new-make-shuffle-mode.html
> that
>    - "make --shuffle" is a way to intentionally provoke failures by adding
>      randomness,
>    - "make --shuffle" assumes that the Makefile is ready for parallel execution
>      (option -j).

I would explain it a little bit differently: "make --shuffle" is a way to 
discover
Makefile bugs by running them in a way which is still compatible with the 
dependencies
specified in them.

In some sense, make --shuffle does not directly provoke the failure, it just
"amplifies" the probability of it happening, but the probability was
already there without make --shuffle.

In this case, for example, the relevant question would be:

How do we ensure that libgnuintl.h exists before trying to use it?

Would this question make sense regardless of the fact that I was
using make --shuffle?

> In GNU, we *try* to support parallel make, see
> https://www.gnu.org/prep/standards/html_node/Makefile-Basics.html
> but there is no guarantee.
>
> So, if you run into a "make -j4" failure, you are welcome to report it.
> But reports produced with "make -j1000" or "make --shuffle" are not
> realistic, and I will not investigate them. If you investigate them
> and come up with a patch that is an obvious improvement, that's another
> story, of course.

Ok, I'm going try to find the positive side of this.

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?

This one in GCC (when building cross-compilers) comes to mind:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081448

The bug contains what I believe it's an obvious improvement.

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...

> > Note: The above error only happened once after several tries during the last 
> > months,
> > so it's random. On the other hand it has all the signs of being a Makefile bug.
>
> Of course it's random, since "make --shuffle" is random by default.

Yes, it happens randomly, but it should never happen if the Makefile was 
correct,
that's the point.

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?

(In such case, I could try to find a given seed which makes gettext 0.23
to fail 100% of the time).

Thanks.