Re: [PATCH] Makefile: add missing dependencies of 'config-list.h'

[Jeff King <peff@peff.net>]

On Fri, Apr 09, 2021 at 12:08:23AM +0200, Ævar Arnfjörð Bjarmason wrote:

> > -config-list.h:
> > +config-list.h: Documentation/*config.txt Documentation/config/*.txt
> >  	$(QUIET_GEN)$(SHELL_PATH) ./generate-configlist.sh \
> >  		>$@+ && mv $@+ $@
> >  
> >  command-list.h: generate-cmdlist.sh command-list.txt
> >  
> > -command-list.h: $(wildcard Documentation/git*.txt) Documentation/*config.txt Documentation/config/*.txt
> > +command-list.h: $(wildcard Documentation/git*.txt)
> >  	$(QUIET_GEN)$(SHELL_PATH) ./generate-cmdlist.sh \
> >  		$(patsubst %,--exclude-program %,$(EXCLUDED_PROGRAMS)) \
> >  		command-list.txt >$@+ && mv $@+ $@
> 
> This change makes sense.

I agree it looks like it's moving in the right direction, but I am
slightly puzzled by the existing code. Why do we need to use $(wildcard)
for git*.txt, but not for the others?

> I have a not-yet-submitted patch series where I added some more
> config/*/*.txt that wouldn't be caught by this rule, I'd updated the
> Documentation/Makefile, but missed this part in the top-level Makefile.
> 
> So a relation question: Does anyone actually prefer this state of
> affairs of having a Makefile, Documentation/Makefile, t/Makefile
> t/perf/Makefile and template/Makefile?
> 
> It seems to me with ever-closer coupling between them that it's getting
> to be more of a hassle to manage state between them than it would be to
> just move them all into one big Makefile.

Yes, I'm generally a fan of avoiding recursive make when we can. I think
the caveats are:

  - it would be nice to continue to have stub Makefiles in
    sub-directories that trigger the main one (so "cd t && make"
    continues to work, for example).

  - we may need some cleanup of parts of the top-level Makefile which
    are triggered without dependencies (e.g., I think we unconditionally
    run some scripts to compute GIT_VERSION in the top-level; this is
    already a bit wasteful, but may get even more so as we add more
    rules from sub-directories).

Mostly my argument against it (and why I haven't purused it) would be:
it sounds like a lot of work and risk of regression, and the current
system seems pretty fine in practice.

-Peff