On 27/03/2022 16:48, Ævar Arnfjörð Bjarmason wrote:

On Wed, Mar 23 2022, Taylor Blau wrote:

quoted

On Wed, Mar 23, 2022 at 03:19:06PM +0000, John Garry wrote:

quoted

For building the linux perf tool we use the git head commit id as part of
the tool version sting. To save time in re-building, the Makefile rule has a
dependency on .git/HEAD for rebuilding. An alternative approach would be to
compare git log output to check current versus previous build head commit,
but that is seen as inefficient time-wise.

Having a Makefile recipe that depends on $GIT_DIR/HEAD seems strange to
me.

Presumably your Makefile rules would map out which parts of your program
depend on each other, and would get invalidated when the source itself
changes, no?

Perhaps you also care about the commit you're building from in order to
embed something into your program. But it seems like you could inject
the output of "git rev-parse HEAD" when you construct the version
identifier whenever you do need to rebuild.

Our very own build process for git.git relies on this, see how version.o
needs a GIT-VERSION-FILE, which we generate by shelling out and
including.

I see.

It is unfortunate that we don't have an advertised way to do this, with
the ref backend I think trickery using $(file) to read the HEAD will
work to do it in pure-make, i.e. you'd need to parse it to see if it's a
symref, then depend on the target it points to.

Or you could recursively depend on a glob of the whole refspace for
generating the version file ...

It would be nice if we had a way to guarantee that we'd write some file
on HEAD updates, AFAIK not even the new reference-transaction hook will
do that (due to "git reset --hard" and friends).

And yes, this does actually matter. There's a huge performance
difference between a Makefile that needs to shell out for every little
thing.

I'm not sure if I mentioned it before, but the main motivation for 
adding the dependency was that "git describe" may be slow. We have since 
moved away from that (using "describe", which I hope turns out to be 
ok), but your GIT-VERSION-GEN still uses it. I just found that "git 
describe" is unreliable for us as it depends on tags being pushed to a 
clone git.

I've been optimizing our own Makefile incrementally from running in
~500ms down to 100-200ms for noop runs over over the last few
months. It's possible to get it down to 10-20ms at least by getting rid
of the remaining shell-outs.

That makes a big difference when e.g. using "make" with "git rebase -i
-x".
.

ok, thanks,
John