bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#68860: race condition with make recheck


From: Bogdan
Subject: bug#68860: race condition with make recheck
Date: Mon, 26 Aug 2024 21:49:53 +0200
User-agent: Mozilla Thunderbird

Karl Berry <karl@freefriends.org>, 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]