Depending on and generating files in system definitions

[Robert Goldman]

On 6/28/16 Jun 28 -7:19 AM, Jan Moringen wrote:
> Hi.
> 
> It seems to be a common pattern to maintain a project's version
> information as a string in a separate file, e.g. version.sexp, and use
> something like
> 
>     (:version (:read-file-form "version.sexp"))
> 
> to get that information into the system definition. This seems like a
> good thing to do as long as version changes are rare and performed
> manually. Unless there is a better way for this simple case, no
> problems or questions so far.
> 
> There are, however, situations in which this doesn't work. My use-case
> is a project which is maintained in a GIT repository and uses the
> following versioning scheme
> 
>     MAJOR.MINOR.NUMBER-OF-COMMITS-SINCE-RELEASE
> 
> This is useful for things like bug reports or determining compatibility
> of input files with the current version of the software. The crucial
> part is maintaining NUMBER-OF-COMMITS-SINCE-RELEASE automatically.
> 
> Previously, I implemented this behavior using some horrible hacks that
> I would rather not talk about. I started from scratch and came up with
> a potential solution (detailed description attached).
> 
> Since this seems like a common problem, I would like to ask whether the
> outlined approach is the proper way to do this. If so, I can try to
> turn the description into something that could be added to the FAQ
> section of the ASDF manual.
> 
> Thanks in advance and kind regards,
> Jan
> 

I only had time for a quick look at this, but it did suggest a couple of
questions:

1. 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?

2. 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).

3. 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.

Hope that helps,
r