On Fri, 29 May 2009, Yavor Doganov wrote: > Francois Gouget wrote: > > But let's say we have something like this: > > > > %.o: %.c foo.h > > some command > > > > Now N.o would still depend on N.c and ultimately on N.y, but it would > > also depend on foo.h. And you're telling me that because of this extra > > dependency, make would be right to try to rebuild N.o without first > > creating N.c? > > No. > > Make in fact sees the first prerequisite of your rule, and knows how > to rebuild it. Because these two prerequisites do not depend on each > other, when the build is run in parallel make is free to process them > together. And because make is smart enough to determine that your > .res file is an intermediate prerequisite whose own downstream > dependencies have not changed, it doesn't even attempt to rebuild it.
What does this have to do with things being parallel or not? Why should 'make -j2' "not even attempt to rebuild the .res file" when when lib.so depends on it? And why then would 'make -j1' decide that it must rebuild it anyway? Any difference in this behavior is a bug. [...] > > However if make decides to rebuild build-foo/lib.so for any reason, > > then doing so when there's no build-foo/rsrc.res file is a bug. > > Right, that's why it succeeds the first time. And why doesn't it succeed the second time? And why does it work the third time? > > Where do you see any dependency order issue in the makefile I > > posted? > > I just suggested a workaround. Ok. Glad to see you agree that the makefile I posted has no dependency order issue. So I hope we can focus on the real problem now. -- Francois Gouget <[email protected]> http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
