On Mar 5, 2024 at 10:06:44, Paul Smith <psm...@gnu.org> wrote: > These two formulations are not really the same: grouped targets work > differently and can't be replaced with an expanded version. A grouped > target: > > a.x b.x &: a.q b.q ; <cmd> > > can only be emulated by something like this: > > a.x b.x : .sentinel ; > > .sentinel : a.q b.q ; <cmd> ; touch $@
This actually comes close to working for my use-case. It fixes the O(n^2) performance issue of having every file depend on every other file since the `.sentinel` intermediate step short-circuits things and only needs to be evaluated once. Unfortunately it forces a full rebuild in my case. The `Makefile` looks something like: ``` .PHONY: output output: output_a output_b output_a: build/a/x build/a/y [ build for a performed here ] output_b: build/b/x build/b/y [ build for b performed here ] build/a/x build/a/y build/b/x build/b/y: build/.sentinel build/.sentinel: src/a/x src/a/y src/b/x src/b/y cp -a src build touch $@ ``` This is a minimal example, but in my case the number of outputs is large and each of those outputs depends upon a few dozen sources. With this style of recipe, if any of the sources is changed it causes `make` to consider `build/.sentinel` stale. This in turn causes all the outputs to be considered stale. What I would like is if I `touch build/a/x` and re-`make`, the whole source directory is copied into the build directory in one go *but* only `output_a` is rebuilt (since the timestamps for everything under `build/b` are unchanged).
