(replying to myself as I'm not subscribed to the ml and thus didn't get Robert's email, sorry).
Thank you for the quick reply, Robert.
I only had time for a quick look at this, but it did suggest a couple of questions:
- Is it necessary to have rsb-version write the version-string.sexp
file? Could you simply override the COMPONENT-VERSION generic function and compute it on the fly from git and version.sexpr?
I omitted the fact that version.sexp can also contain the complete version specification in which case rsb-version writes version- string.sexp without consulting git. This mode is intended for installing or packaging the sources independently of the git repository.
One use case for this ability is packaging the source with cached version information and copying it into the workspace of a different project in a continuous integration scenario.
Also, shelling out to git for each COMPONENT-VERSION method call seems expensive to me (But maybe I'm just paranoid since my previous solution was super inefficient and wasteful).
- How does this work across developers? Couldn't you end up in a
situation where two developers have versions x.y.z and x.y.z' where z = z' but the two systems are different (because they are on different git repositories with differing histories)? In an ideal world, the version identifier should identify a unique state of the codebase, yes?
I suppose one could get the version identifier from some shared history (like the remotes/origin branch).
The requirement here is mostly that non-lisp-developers (or even non- developers) can build (and pull + re-build) the master branch and release branches of the project and automatically get a binary with detailed and accurate version information.
I guess rsb-version could also writes a version-details.sexp which would include the commit id. But I cannot see how that would work as an ASDF system version (I seem to recall that net.didierverna.clon has something like that and ASDF seems to get upset about it).
- Your rsb-protocol-config system seems quite reasonable. We have
done things like this to, for example, invoke "make" to build required non-lisp code.
Good, thanks.
Again, thanks for the quick reply and valuable feedback.
Kind regards, Jan