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

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

quoted

-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