Jeff King [off-list ref] writes:
On Tue, Jan 26, 2021 at 05:07:04PM +0100, Ævar Arnfjörð Bjarmason wrote:
quoted
This small series speeds up builds where you just want to get to a
working "git" binary, but don't care about running git's own tests, or
about making/installing fallbacks for "git svn" et al (which we do
even with NO_PERL).
I have to wonder if you really care about non-builtins here. If not,
then doesn't "make git" do what you want?
I had the same thought, while wondering if all the ugliness in [4/4]
is really worth it.
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?
And if we are not doing [4/4], I suspect [1/4], while it is not bad
as a clean-up, would become less attractive.
So...
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).
-Peff