Steps to reproduce problem: 1. Update an existing tree so that one of the config.status dependencies is newer than config.status and Makefile 2. Try to rebuild using $(MAKE) -f $(srcdir)client.mk Expected result: client.mk runs configure once Actual result: client.mk runs configure twice This is caused by the following bogus rule in client.mk: $(OBJDIR)/Makefile $(OBJDIR)/config.status: $(CONFIG_STATUS_DEPS) @$(MAKE) -f $(TOPSRCDIR)/client.mk configure Since both files are out of date, pymake runs configure twice, once for each file. This is correct behaviour! You don't notice it with gmake because client.mk contains .NOTPARALLEL and gmake evaluates each dependency lazily, so by the time Makefile has caused configure to be run, gmake realises that config.status is now up-to-date and doesn't bother running it again.
Created attachment 558190 [details] [diff] [review] Proposed patch Because (except in special circumstances, such as making both foo.h and foo.c from foo.yy) gmake doesn't actually allow you to have two different files depending on the same command, normal attempts at ensuring dependencies fail. In particular, if Makefile does not exist, then we can't make it depend on config.status, because gmake won't know how to remake it. So instead we make Makefile depend on $(CONFIG_STATUS_DEPS) directly in that case.
Comment on attachment 558190 [details] [diff] [review] Proposed patch >-$(OBJDIR)/Makefile $(OBJDIR)/config.status: $(CONFIG_STATUS_DEPS) >+ifneq (,$(MAKEFILE)) >+$(OBJDIR)/Makefile: $(OBJDIR)/config.status >+ >+$(OBJDIR)/config.status: $(CONFIG_STATUS_DEPS) >+else >+$(OBJDIR)/Makefile: $(CONFIG_STATUS_DEPS) >+endif > @$(MAKE) -f $(TOPSRCDIR)/client.mk configure I didn't know you could do if condition SOME TARGET: SOME DEP else SOME OTHER TARGET: SOME OTHER DEP endif RECIPE
Pushed changeset e095afa62bf5 to mozilla-central.
Pushed changeset a060508db9b3 to comm-central.