Francois Gouget wrote:
> > Make in fact sees the first prerequisite of your rule, and knows how
> > to rebuild it...
> What does this have to do with things being parallel or not?
Nothing, indeed. It should have nothing to do with that; it seems
that during the dependency check with -j2 make incorrectly "loses"
this information and fails to discover that it needs to rebuild the
non-existing target.
At first glance I thought this has to do with a famous bug in the
Linux build system, which current make workarounds:
if (!running)
/* The prereq is considered changed if the timestamp has changed while
it was built, OR it doesn't exist.
This causes the Linux kernel build to break. We'll defer this
fix until GNU make 3.82 to give them time to update. */
d->changed = ((file_mtime (d->file) != mtime)
/* || (mtime == NONEXISTENT_MTIME) */);
But this is not related to intermediate files, AFAIK. (This future
change is in the NEWS, actually.)
The following change also seems related to the issue you're observing:
2007-08-15 Icarus Sparry <[email protected]>
* remake.c (check_dep): Reset the target state for intermediate
files. They might have been considered before but not updated
then (order-only for example) but they will be this time.
Fixes Savannah bug #'s 3330 and 15919.
(Savannah is down now, so I can't check the bugs, but by memory the
latter had long debate.)
> > Right, that's why it succeeds the first time.
>
> And why doesn't it succeed the second time?
Because the second time is a rebuild, so it reaches the (apparently
wrong) conclusion that this target doesn't need uptading.
> And why does it work the third time?
Because your recipe has "|| rm $@" so the target does not exist.
I checked with CVS trunk, same behavior. Make 3.80 does the right
thing, though, so I'm convinced now that this is a genuine bug.
Probably very well known upstream already, but in any event it's
definitely worth investigating.
I apologize for not checking the -d output right in the beginning and
resorted to splitting hairs :/
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
