Hi Peff, On Mon, 15 Apr 2019, Jeff King wrote: > 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. *Sigh* I really did not want to do that because I thought it would be tedious and more complicated and result in a longer patch. Well, don't you know. The patch is actually *a lot* shorter now. So much so that range-diff thinks it is a different commit ;-) Thanks for the reality check/prod, Dscho
