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.
