Jeff King <peff@xxxxxxxx> writes: > On Tue, Jan 26, 2021 at 05:38:08PM -0800, Junio C Hamano wrote: > >> The steps 2/4 and 3/4 did look like a useful feature, but I wonder >> why we even need to introduce NO_TEST_TOOLS in the first place. >> Wouldn't it be more natural to arrange them to be built by making >> "test::" target depend on them? IOW, why do we need to have "all::" >> (our default) target depend on them? > > Hmm. That is definitely more logical, and giving "make" more information > to make a good decision about what is needed. I do wonder if it would be > annoying in two cases, though: > > - people trigger the tests in other ways besides "make test". For > instance, "make && cd t && make" works, as does just > "make && cd t && ./t1234". With a more clever Makefile, those would > fail (or worse, run out-of-date versions of the helpers, producing > confusing results). > > - during refactoring, I often compile-test as I go (i.e., run "make" > to see which callers still need changed, then fix them, repeat). > If that didn't catch test helpers, then I'd think I was done and get > bit later by "make test" trying to build more code. Not the end of > the world, but a minor annoyance. > > So I think even though I'd argue that giving "make" that extra > dependency information is "more correct", we are fighting uphill against > existing behavior, as well as things that make doesn't know (like that I > expect to be ready to run tests as long as "make all" has finished). Hmph, true, but as "make test" at the top-level merely redirects to "make -C t", I imagined that the default target in the t/Makefile would depend on doing "make -C .. test-programs" before running tests. The recursive dependencies end somewhere, though ;-)
