configure: META.in template with no hardcoded version number

[gasche]

No description provided.

[gasche]

@dbuenzli I use your git describe trick in 6318427 , now also part of this PR.

I still kept the VERSION file because that allows building from the source repository as it from the result of a git archive file. If I only relied on git describe, we would have to add an extra tarballization step before sending our source to users, and I would rather avoid that as long as it seems reasonable to do so -- I know it's not your process, but I like the simplicity of releasing exactly the development sources at a given time.

[gasche]

I added a make check-release target that checks that VERSION and git describe coincide, and that NEXT_RELEASE occurrences are gone from source files.

[bobot]

Instead of rebuilding each time you can do that:

#force allows to always run the rules that depends on it
.PHONY: force

#.version_stamp remember the last version for knowing when rebuilding
.version_stamp: force
    @echo '$(VERSION)' | cmp -s - $@ || echo '$(VERSION)' > $@

And make src/ocamlbuild_config.ml depend on .version_stamp

[bobot]

However since it is in configure.make it is not really important.

[bobot]

Except for when the META is created I think my other remarks can be postponed. So you can merge, just after fixing the META problem. I'm going to use the merge point for 0.9.1.

[gasche]

Would it be ok to create the META at configure time? I don't see a good time to request it at build time.

[bobot]

The all phony target depending on it is natural to me.You can do it at configure time but later I hope we can move the version detection to the compile time, otherwise when we checkout a new branch the version is not updated, no?

[gasche]

Semantically the "best" way to do it is to use your .version_stamp technique which give pixel-perfect dependencies for the whole codebase. The thing that I find unpalatable with this is that it means that, in particular, each commit will force complete recompilation, as the version value will have changed. Maybe I'm just too careful and this is actually the semantics we want? What do you think? If so, would you send a PR on top of my META-template branch to implement this behavior?

Another way to take this is that having such a precise git describe is maybe not a good idea, and that we should either revert to just trusting VERSION (which I think is mostly fine as long as we are careful to update it at release time, which is not too much work), or maybe as an alternative take branch name + dirty, but not the middle stuff with the number of commits since the branch or a commit hash (which could be difficult to act upon anyway)..

[dbuenzli]

Another way to take this is that having such a precise git describe is maybe not a good idea

When you develop and build in the repository you don't really care about having precise version numbers since you have the git repo at hand to understand what is going on. You really care about precise git describe whenever you install either via pin or for a release.

(which I think is mostly fine as long as we are careful to update it at release time, which is not too much work)

The only way of doing this reliably is if you stop fiddling with version numbers manually and let the information automatically come from the place where it is stored which is the vcs. By doing this you know that whenever you ask someone to give you the output of ocamlbuild -version you can fully trust the answer. This will both be appreciated by people you ask for testing fixes by pinning and yourself, unless you like to lose your time and the one of your users with software that lies to you about its current build state.