Hi Try this Makefile: --- a : b echo build a touch a
b : c echo build b touch b --- and run this script: touch b;sleep 1;touch a c;make You see "echo build b build b touch b" but it doesn't remake a. The apparent problem is that after make rebuilds b, it compares b's time with a's time, finds that the times are equal (because a was touched just before make was run) and doesn't rebuild a. I think it is a bug - when b is finished, make should find out whether the rule for b modified the file b (if b's time is greater or equal than the time when the rule for b was started, then b may have been modified) and rebuild a in this case. --- This bug is causing real-world problems in automake-generated Makefiles. This is a simplified piece of Makefile from automake: all : config.h $(MAKE) all-am config.h : stamp-h1 echo build config.h stamp-h1 : config.h.in echo build stamp-h1 rm -f stamp-h1 touch config.h touch stamp-h1 config.h.in : am__configure_deps echo build config.h.in rm -f stamp-h1 touch config.h.in all-am : echo ALL-AM Now, if you run this script, you trigger the bug: touch config.h.in;sleep 1;touch am__configure_deps;sleep 1;touch config.h stamp-h1;make - you see "build config.h.in", but the other files are not rebuild and all-am is executed (the essential thing to trigger the bug is that make is run in the same second in which config.h and stamp-h1 were created) The problem that really happens in a real build: * The user runs autoheader && aclocal && automake && autoconf && ./configure && make -j4 * Configure runs ./config.status, ./config.status writes config.h and stamp-h1 * Make sees that am__configure_deps is newer than config.h.in * Make runs the rule for config.h.in. It sets the new timestamp for config.h.in and deletes stamp-h1 * Now make sees that config.h.in has the same time as stamp-h1 (the timestamp is read from make's cache even if stamp-h1 no longer exists) * Because of the same timestamp, make doesn't run the commands for stamp-h1 and config.h * Make executes a subprocess to build the rule all-am * The subprocess doesn't have the file cache of the parent process, so the subprocess knows that stamp-h1 is missing * The subprocess sees a dependency config.h->stamp-h1, stamp-h1 doesn't exist * The subprocess executes the rule for stamp-h1 which regenerates config.h - the problem is that this rule is executed in parallel with other rules that build C files that include config.h - changing config.h while it is being used results in build failure Another possible solution for this bug would be to remove rm -f stamp-h1 from config.h.in rule, but there is some complex explanation in /usr/local/share/automake-1.12/am/remake-hdr.am why rm -f stamp-h1 is there so it would likely fix one bug and trigger another one. So it would be better to fix this in make. Mikulas