bug#68860: race condition with make recheck

Karl Berry <[email protected]>, 2024-08-25 19:17:
>      >      -  $output_rules .= "check-am: all-am\n";
>      >      +  $output_rules .= "check-am: all-am";
>      >         if (@check)
>      >           {
>      >      -      pretty_print_rule ("\t\$(MAKE) \$(AM_MAKEFLAGS)", "\t  ", @check);
>      >      +      $output_rules .= " @check";
>
> Looking again, the comment before this code says:
>
>    # The check target must depend on the local equivalent of
>    # 'all', to ensure all the primary targets are built.  Then it
>    # must build the local check rules.
>
> .. which makes sense. We have to make all before we can make check.
> Hence the check targets can't be dependencies, since then they would be
> run in parallel with make, and the programs built by 'all' might not be
> built yet. This explains why they made it a sub-make.


  Totally makes sense, and I'm not removing the dependency on all-am.
When I see that the first command of a target is a 'make', I start
thinking that something in dependency management is wrong. It
shouldn't be needed, right? That's one of the jobs 'make' does -
figure out what needs to be built and in what order. So, if the
dependencies would be correct in the first place, maybe running 'make'
in a target wouldn't be needed (well, not in the beginning, at least).
That's why I'm adding @check to the dependency list instead of
building it manually as the first command. The dependencies /should/
be computed correctly and built just once (if needed, that is).

  But, correct dependencies are maybe just in the perfect world.

  There probably were reasons to do it this way, like parallel make
(which /should/ work correctly, but maybe not all implementations do)
or some implementations that e.g. don't follow the order and break the
builds because of that, or too many too complicated dependencies to
put on each target, or...

  So, what do we do? It has just become a bit scary to apply the
patch, but it looks like it's exactly the dependency list that should
be fixed...


> So I'm puzzled as to how all the tests can still be passing. Maybe there
> is no test specifically for this? --thanks, karl.


  Maybe. Or maybe tests pass on the well-behaving GNU Make, but not on
all 'make's. Or I didn't run the "right ones".


--
Regards - Bogdan ('bogdro') D.                 (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):    http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org