pkg/pkg.mk: make sure we are building the correct commit.

[jcarrano]

Contribution description

This solves an issue I ran into while trying to figure out what was happening with edbg. I had two git worktrees and I had two different reset behaviours even though the PKG_VERSION of edbg was the same in both trees. Upon closer inspection I discovered that in one tree PKG_VERSION and the actual HEAD commit of edbg did not match.

Once the repo is downloaded, the version is not checked gain. This means that even if a package's Makefile is touched, that will only cause a rebuild of the previously downloaded version. For packages
that are normally not deleted, like edbg, this renders PKG_VERSION bumps ineffective, unless the user manually deletes the repo directory.

This patch fixes that by always checking that the repo is at the right commit.

Testing procedure

I included a throwaway commit to make testing easier.

After checking out this, the first step is to go backwards to the commits before this PR, clean edbg, and download it and build it again:

# go before my first commit
$ git checkout 6ff1a57^
$ rm -rf dist/tools/edbg/edbg dist/tools/edbg/bin
$ make -C examples/hello-world $(pwd)/dist/tools/edbg/edbg
$ grep VERSION dist/tools/edbg/Makefile && git -C dist/tools/edbg/bin rev-parse HEAD
PKG_VERSION=807d948cc8a664ade3e9446b4937aa54268afcb2
807d948cc8a664ade3e9446b4937aa54268afcb2

Now let's try to bump the version:

$ git checkout 6ff1a57
$ make -C examples/hello-world $(pwd)/dist/tools/edbg/edbg
$ grep VERSION dist/tools/edbg/Makefile && git -C dist/tools/edbg/bin rev-parse HEAD
PKG_VERSION=ba864ebc46e985cb400ccdd63cdafaccbc3698c0
807d948cc8a664ade3e9446b4937aa54268afcb2

D'oh! that's not what we want. Now with the fix:

$ git checkout a0c709f
$ touch dist/tools/edbg/Makefile
$ make -C examples/hello-world $(pwd)/dist/tools/edbg/edbg
$ grep VERSION dist/tools/edbg/Makefile && git -C dist/tools/edbg/bin rev-parse HEAD
PKG_VERSION=ba864ebc46e985cb400ccdd63cdafaccbc3698c0
ba864ebc46e985cb400ccdd63cdafaccbc3698c0

Issues/PRs references

Found when investigating #11125 .

[jcarrano]

NOTE: this is for testing only.

[dylad]

Interesting feature. Works like a charm with SAML21-XPRO !
Not a makefile expert so I leave the in-depth review to someone else but this PR should be not be harmful.

[dylad]

one side note and I don't know if it's feasible or not.
Would it be useful to add a visible warning (yellow line ?) to inform user that edbg cannot be rebuild due to lack of internet connection so it keeps the previous version ? Just wondering.

[jcarrano]

@dylad I think that we should see versions (at least now, with the current model) as a "hard" requirement. The reason is that it is impossible to know if the old version works fine, or has incompatibilities, or a security issue or a bug. If we were using a kind of "version number" scheme, we would be able to be a bit smarter on wether we can fulfill the requirements without upgrading, but as it is now, allowing that kind of behavior can possibly lead to errors.

Why not define an "update-tools" target instead? That way you can be sure that you have up-to date tools for whatever version of RIOT you may be using.

[dylad]

ACK on my side.

@jcarrano could you squash please ?

Why not define an "update-tools" target instead? That way you can be sure that you have up-to date tools for whatever version of RIOT you may be using.

This is an interesting idea, but I'm quite happy with this PR as it.

[jcarrano]

I removed the test commit.

Why not define an "update-tools" target instead? That way you can be sure that you have up-to date tools for whatever version of RIOT you may be using.

A problem with my suggestion is that it would require having a central listing of all tools and manually maintaining it, which is ugly.