On Thu, May 28, 2009 at 06:10:01PM +0200, Francois Gouget wrote:
> On Thu, 28 May 2009, Yavor Doganov wrote:
> > Yes, but you have not stated any order of these prerequisites [...]
> That's were you lost me.
Sorry, my explanation was confusing. Make treats intermediate files
differently and does not bother updating one in certain situations.
Here, in your case, the job which processes your lib.so rule insists
on satisfying only the second prerequisite, because the first one is
computed via chained rules and is an intermediary file.
Note that if the rsrc.res rule was not a pattern rule, like this
build-foo/rsrc.res: build-foo/rsrc.rc
cat $< >$@ || rm $@
then doing `make build-foo/lib.so' would have caused make's rule
search algorithm to find out that there's an explicit rule for this
file, and it would always consider it. (Of course it won't delete
this target after running the rule, because by virtue of being a
prerequisite and an actual target, it is not "intermediate" anymore.)
> Doesn't the above rule mean that before rebuilding lib.so we must have
> both build-%/rsrc.res and build-%/main.o?
In general -- yes, but this is not guaranteed. Make simply decides it
can go on without rsrc.res here:
,---- (make)Chained Rules ----
| The first difference is what happens if the intermediate file does
| not exist. If an ordinary file B does not exist, and `make' considers
| a target that depends on B, it invariably creates B and then updates
| the target from B. But if B is an intermediate file, then `make' can
| leave well enough alone. It won't bother updating B, or the ultimate
| target, unless some prerequisite of B is newer than that target or
| there is some other reason to update that target.
`-----------------------------
This is a common parallel-safety bug in makefiles, I'd say. Having
pattern rules with multiple prerequisites which are derived via
chained rules is a luxury, so you'd have to take the necessary steps
to convince make about the order of dependencies. Or invent an
artificial one, if the situation allows.
> What do you suggest?
I'd mark it as .PRECIOUS, but there are several approaches depending
on what you actually want to achieve in the real-life case. I don't
think this is a make bug, though.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
