On Mon, Apr 15, 2019 at 12:16:51AM -0400, Eric Sunshine wrote: > On Sun, Apr 14, 2019 at 11:10 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes: > > >> +Documentation/GIT-EXCLUDED-PROGRAMS: Makefile config.mak.uname > > >> + $(QUIET_GEN)echo "EXCLUDED_PROGRAMS := $(EXCLUDED_PROGRAMS)" >$@ > > > > > > Should this rule also have a dependency upon "config.mak.autogen"? > > > > That is probably a good point. > > > > > Perhaps like this: > > > > > > Documentation/GIT-EXCLUDED-PROGRAMS: Makefile $(wildcard config.mak*) > > > > I'd rather not let changes to "config.mak-", which I keep in my > > working tree (untracked and disabled copy of config.mak, that can be > > readily activated by renaming), be part of dependency rules. > > > > If we know 'autogen' is the only dependency that optionally can > > exist, then depending explicitly on $(wildcard config.mak.autogen) > > would be a better alternative. > > When composing that email, I originally wrote $(wildcard > config.mak.autogen) as the suggestion but changed it to the looser > $(wildcard config.mak*) when I realized that the developer's own > config.mak probably ought to be a dependency, as well. Taking your > objection into consideration, we could mention both explicitly: > > Documentation/GIT-EXCLUDED-PROGRAMS: Makefile \ > $(wildcard config.mak) $(wildcard config.mak.autogen) What about command-line options that influence the outcome? It sounds like this is the same problem we have in lots of other places (like say, compiler flags being updated), that we solve by generating the proposed file output unconditionally and comparing it to what's on disk. E.g., see the way GIT-CFLAGS or GIT-BUILD-OPTIONS is generated. -Peff
