On Mon, Feb 04, 2013 at 01:29:41AM -0800, Junio C Hamano wrote: > Junio C Hamano <gits...@pobox.com> writes: > > > As I understand how the current set-up works: > > > > * Initially, we do not have foo.o but foo.c. We automatically > > build foo.o because it depends on foo.c via the "%.o : %.c" rule, > > and as a side effect, we also build .depend/foo.o.d file; > > > > * Then, if any real dependency used to build the existing foo.o > > that is recorded in .depend/foo.o.d file changes, foo.o gets > > rebuilt, which would update .depend/foo.o.d again for the next > > invocation. > > This is unrelated to the case you mentioned, but I wonder what > happens if you did this: > > * You are on branch 'next', where foo.c includes (perhaps > indirectly) frotz.h. Compile and you get foo.o and also the > dependency recorded for it, "foo.o: foo.c frotz.h", in the > .depend/foo.o.d file. > > * You check out branch 'master', where foo.c does not include > frotz.h. Indeed, the include file does not even exist on the > branch. > > Do we get confused, because Makefile includes the depend file from > the previous build, finds that you need foo.c and frotz.h up to date > in order to get foo.o, but there is no rule to generate frotz.h?
No, because the .d files look like this: foo.o: frotz.h frotz.h: So make sees that it can build frotz.h, which of course does nothing. But that's OK, because foo.c doesn't actually include it anymore, and when we recompile it (as we must, since it is different between the two branches), we will rewrite the .d file without frotz.h. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
