Re: [PATCH v2 0/3] Makefile: fix issues with bin-wrappers/% rule

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Thu, Oct 27 2022, Jeff King wrote:

> On Wed, Oct 26, 2022 at 04:42:34PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> This simple topic fixes issues with the bin-wrappers/% rules, as seen
>> in the range-diff below this never worked properly:
>> 
>> 	make bin-wrappers/git
>> 
>> I.e. we'd make the scirpt, but not "git".
>
> Maybe I'm missing something, but the current behavior is what I'd expect
> to happen. Sure, bin-wrappers/git depends on "git" at run-time if you
> want it to do something useful. But AFAIK it doesn't at build-time. Why
> do we want a build-time dependency?  Are we expecting rules to depend on
> bin-wrappers/foo but not also on foo? Or people to ask manually for
> those targets?

I didn't have an immediate practical reason for it beyond just not
leaving holes in the dependency DAG.

But yes, nothing is only building bin-wrappers/% now, so nothing needs
this. It just helps to not have to worry about Makefile targets not
needing other targets to work.

> This kind of feels like making git-repack depend on git-pack-objects.
> One will call the other at run-time, but there's no reason the builds
> have to be together. And if you try to build and run one without
> building the other, well...if it hurts, don't do it.

Or wget depending on your router being plugged in? Beacuse that's what
you use it for?:)

I get the general point, but I don't think these are comparable to those
sorts of loose or semi-loose dependencies. For repack it'll service up
e.g. "-h" without pack-objects, at least that's something...

Whereas these scripts all end with invoking the binary corresponding to
their name, so they really are useless without that target. So I think
it makes sense to make it a dependency of the target in the Makefile.