Re: perf version issues

From: John Garry
Date: Thu Mar 24 2022 - 13:09:39 EST


+ Ingo

On 23/03/2022 12:44, John Garry wrote:
$ git cherry-pick cb66befccba18fac
   [perf/core 8ff6a6c06a90a362] perf tools: Fix version kernel tag
    Author: John Garry<john.garry@xxxxxxxxxx>
    Date: Mon Feb 21 21:16:49 2022 +0800
    1 file changed, 4 insertions(+), 9 deletions(-)
   $ make -C tools/perf O=/tmp/build/perf install-bin
   $ perf -v
   perf version 5.17.rc8.g4e666cdb06ee

Now it doesn´t notice it and there is no automatic rebuild triggered, we
stay with the cset from before the cherry-pick:-\

$ git log --oneline -2
8ff6a6c06a90a362 (HEAD -> perf/core) perf tools: Fix version kernel tag
4e666cdb06eede20 perf tools: Fix dependency for version file creation
$

Anyway, your patch works for some cases, so its an improvement and I'll
apply it, we can continue from there.

After some experimentation, I find that only .git/HEAD changes for a cherry-pick depending on whether we're on a branch or not. As such, as you have seen, we may not rebuild after a cherry-pick, which is no good.

As far as I can see, only .git/index changes in all circumstances, but we don't have a dependency on that.

TBH, using .git files as Makefile dependencies doesn't seem to work well.

Maybe we should output "git log" and check versus what we have in PERF-VERSION-FILE and re-build depending on that.

Let me check this further now.

Just an update on this...

I did some research and found that Ingo introduced the change to make .git/HEAD a dependency as a build optimisation. See commit commit c72e3f04b45fb2e50cdd81a50c3778c6a57251d8 ("tools/perf/build: Speed up git-version test on re-make")

According to the commit log it's quicker to trigger a rebuild of the version string depending on a change in a git internal file rather than run "git describe" to see any change in tag/commit every times.

However, I asked the git community about this approach, and their general idea is that a dependency on .git/HEAD or other git internal file is just not a good idea.

See https://lore.kernel.org/git/87wngkpddp.fsf@xxxxxxxxx/T/#m4a4dd6de52fdbe21179306cd57b3761eb07f45f8

So to get this working robustly we may need to roll back that named commit in part.

Thanks,
John