Meson: git version

[elmarco]

Many projects rely on git generated version. git itself, and there is the popular http://git.savannah.gnu.org/cgit/autoconf.git/tree/build-aux/git-version-gen for autoconf. Other projects use similar scripts.

It would be great if meson had a 'git-version-gen' option in project()

[jpakkane]

This should do what you need.

[elmarco]

Interesting, but how does that help to specify the project version?

[jpakkane]

It can't. Project versions must be written by hand and be explicit. It must also work when Git is not installed. The common approach is to have a sensible version number in project and put the git hash in config.h or similar so you have access to both.

[elmarco]

It's not the same though, git-version-gen allows to generate incremental version for each commit, and avoid having hard-coded version duplication. It's not simply about the git hash.

[nirbheek]

I'm not sure I understand how that's not covered by the vcs_tag command. git commit ids change as soon as you do a rebase or any operation that rewrites history. Even cherry-pick rewrites the commit id. Could you please explain your use-case a bit more? What sort of versions does git-version-gen generate? How are they incremental?

[tp-m]

By default vcs_tag will output something using git describe such as 0.33.0-22-g58359c8 which basically means 22 commits after the 0.33.0 tag, with head at commit 5835...

[elmarco]

What is project() version used for? According to reference manual, it's just for later reference with meson.project_version(), but if you use vcs_tag you'll probably not use it.

Similarly what is the project name for? I can't even find a 'dist' target.

Is there a way to list available targets?

Btw, it would be quite helpeful if the reference manual had function declarations: project(project_name, language1, _language2_ ...)
optional keywords: version, subproject_dir, meson_version, default_options

Meson is quite confusing when coming from autofoo or even plain Makefile, and documentation has a lot to be desired.

A guess a more complete hello-world project (not just http://mesonbuild.com/samples.html or test cases in meson.git), including binary, static library, shared library, tests.. would help a lot.

[elmarco]

I wish there would be a meson version of GNU hello: http://git.savannah.gnu.org/cgit/hello.git

[jpakkane]

Project versions are used when importing subprojects. They allow you you specify version limits similar to dependency like this:

foo_sp = subproject('foo', version : '>=1.0.0')

The wiki has a more in-depth tutorial, which should be what you want.

The function declarations thing is a known issue. Unfortunately Github's wiki formatting is limited so it is hard to make it look similar to e.g. gtk-doc output.

[nirbheek]

Is there anything else you need here, @elmarco?

[elmarco]

@nirbheek I haven't tried recently, and I have not good knowledge of meson. Afaik, it's not possible to let the version be generated from git describe, like git-version-gen does.

[elmarco]

It's almost possible to use an approach similar to git-version-gen, since you should be able to run_command() like that:

version: run_command(['git-version-gen',
                      '$MESON_SOURCE_ROOT/.tarball_version']).stdout()

However, there is no easy way I can think of to ship .tarball_version... That file should be generated at dist time, and not kept in the build directory after dist, but should be included in dist.

[smcv]

However, there is no easy way I can think of to ship .tarball_version...

Resolving #2166 would provide one, I think?

[madig]

I am also interested in having some automagic git tag versioneering, much like https://github.com/pypa/setuptools_scm. It's just so convenient to not have to do boring version bump commits and being able to do a release by tagging a commit in a UI.

[axxel]

Question for @elmarco: if the vcs_tag() call would do what it currently does inside a version controlled source tree and would 'magically' transport the version info during a dist step into the tarball, such that if you built the extracted tarball with meson again, it reproduces the info that it stored during the dist, would that be what you are looking for with your git-version-gen request?

[elmarco]

@axxel that sounds like it would be enough.

fwiw, Eduardo Lima managed to somehow use git-version-gen in spice-gtk:

https://gitlab.freedesktop.org/spice/spice-gtk/blob/master/meson.build#L5

I haven't looked at the details, but my feeling is that this could be simplified by some common meson facilities.

[elmarco]

actually, his solution doesn't work, tarball-version isn't shipped, and make dist fails.

[axxel]

Even if it would work, it would not be quite the same thing: the vcs_tag() sets up a 'build_always' target that checks on _every_ build if the state of your wc changed. The idea was to make sure you don't accidentally ship uncommitted changes by typically adding a '+' to your version string in that case. Executing some script during the 'global configure' step will not provide that.

Also, I was not proposing to somehow make the meson.project_version() 'automacially' return the vcs version of the current wc, albeit I would see the conceptual benefit of that: You'd had only one kind of version to reason about. It would also naturally fix #3903.

@jpakkane: would you consider merging something along the lines of:

project('name', 'c', version : vcs_tag(template: '1.0.@VCS_TAG@'))

It would make the vcstagger.py simply rerun the config process as if meson.build had changed (instead of generating some output file). The template parameter could have a default value of '@VCS_TAG@'. Putting the information into some config.h would then simply use the existing configure_file() machinery. The question of how to transport the version info from the wc to a tarball is independent of this new approach. Thinking about it for a few minutes makes me regret to not have come up with this idea when I first implemented the vcs_tag(). I might very well be overlooking some fundamental issues with this 'full rerun' approach, though.

[elmarco]

@axxel @jpakkane has there been any update for this?
thanks

[axxel]

Since I got no reaction from Jussi to my "would you consider merging...?" question above, I did not further investigate this idea.

[xclaesse]

I think it would make sense to have it as new function (e.g. vcs_tag_string()) that returns the version as a string. I don't think you need a template argument because you can do it as '1.0.@0@'.format(vcs_tag_string()).

From an implementation POV, it would be a build_always target that spawn meson --reconfigure in case the version changed. Note that means each commit would trigger a reconfigure, not sure that's what people here wants.

@jpakkane any objection?

[jpakkane]

Any system that sets up the vcs tag version via a meson.build definition is not really reliable because if you do new commits they don't necessarily trigger a Meson reconfiguration. To get that reliable we'd need to rerun reconfigure on every change, which would be too slow.

[axxel]

Just to make sure I understand your objection correctly: a reconfiguration would be necessary after every WC state change (like commit, checkout, etc.) not on every build attempt. How long does a reconfiguration after a manual change of the version info in the project()-line take on a 'large' project?

[jpakkane]

Worst case that I know of is tens of seconds.

But even worse is that it changes an operation (empty build) from something that is instantaneous to something that is noticeable. This is poor UX.

[axxel]

Tens of seconds sounds not very nice (in and of itself) indeed. But going one step back and looking at the issue from a top level point of view, this cost is what you _have_ to pay for getting an up to date version info for your project then, whether you provide it manually by changing the build file or have meson figure it out from the vcs. So if your version template only contains e.g. git tags and no commit hash, then you'd pay the very same price but without the requirement to keep your version info in sync manually (which is, of course, what this whole vcs-tag-feature is all about).

Apart from that: would it not be possible to speed up the reconfiguration by caching data if the only change is known to be the version string?