Follow-up Comment #11, bug #44742 (project make): The patch is attached to the ticket separate from my comment:
https://savannah.gnu.org/bugs/download.php?file_id=37212 For the first change, it makes no sense to me to propagate a timestamp on a remade rule to an unremade rule. Which the f_mtime() function is doing (verified in debugger) when called from remake.c:179 (of git tree 4c9e10f). We could try to ensure that f_time is never called when it is not safe to propagate a timestamp to all the double colon rules, but it is more robust to make f_mtime() itself do the check so that f_mtime() can be used more freely. For the second change, notice that the problematic timestamp propagation was happening at remake.c:179 but, in the non-parallel case, a loop forcing all the double colon targets to be remade before that happens at remake.c:358. But for the parallel case, that loop only queues jobs and all of the rules will be considered later after the next reap_children() after the timestamp mistake occurs. The loop is referenced in the changelog: 1999-12-02 Paul D. Smith <psm...@gnu.org> * remake.c (update_file): Move the considered test outside the double-colon loop, _but_ make sure we test the double_colon target not the "current" target. If we stop early because one double-colon target is running, mark all the rest considered and try to start their prerequisites (so they're marked considered). Fix for PR/1476 suggested by Tim Magill <tim.mag...@telops.gte.com>. I don't know what bug 1476 was and don't know how to find it on the internet, but I suspect it was to fix an issue regarding an insufficient number of double-colon rules being run due to the timestamp propagation in f_mtime. I could be wrong, but I'll believe this loop is unnecessary until somebody explains to me why we need it. I left it in only to make my change more conservative in that it only impacts parallel builds with double colons. Disclosure: I do not understand why other, earlier, calls to f_mtime() have not been an issue. Now, supposing I'm wrong about something or that I misunderstand something, it does not matter much, because it is easy to prove that my change does not affect any of make's behavior unless it is running parallel and it includes double-colons. A situation that is currently badly broken and a situation, which, empirically, my change fixes. So I feel justified in submitting the patch even with an incomplete understanding. _______________________________________________________ Reply to this item at: <http://savannah.gnu.org/bugs/?44742> _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
