CODEWITHSUNDEEP
gitversionautotoolsconfigure
jonthalpy
jonthalpy

Reputation: 1051

Can I make my configure script define the VERSION variable from a file instead of being hard coded?

I'm diving into autotools and have successfully gotten most of my build process down, but I've recently hit a snag keeping track of the VERSION variable. We develop as a group using git, and currently have a system in place that bakes part of the git commit hash into a version string that is part of our library. This way, when we have compiled code it's easy to check which commit it was compiled from. For example if we run mything --version it prints 0.1.1.1f034b7.

My current solution to do this with autotools involves having a version.sh script in the repository that probes git for the commit hash and outputs the version string as shown above. Then in configure.ac I've got

AC_INIT([example], [m4_esyscmd([./version.sh])], [[email protected]], [], [amazingcode.com])

With this I can run autoreconf -i, generate a configure script and do the usual ./configure && make && make install. By runing ./configure, a file in the project called version.cc is created from version.cc.in, by substituting @VERSION@ with the version string I want. This is where the function relevant to mything --version resides.

Though, this works, I dislike the fact that every time I make a commit, I have to rerun autoreconf -i, because with each commit made, the configure script gets out of date.

What I'd like to do is have the generated configure script know that the VERSION variable isn't some hard coded string. Instead, I could have version.sh save the version string to an untracked file that the configure script would read to determine what VERSION should be.

Is this possible without too much macro witchcraft? I want to set the version stuff up once and forget about it. I'm open to alternative solutions as well, but it'd be nice not to require other developers to install autotools in order to contribute.

I know there's some strong opinions on automake and build systems in general. Please refrain from telling me how much you hate autotools. I'm pretty new and still learning, but I honestly don't think it's bad at all. Thank you!

Upvotes: 2

Views: 1330

Answers (1)

ldav1s
ldav1s

Reputation: 16305

I've done something like this before. I left VERSION a static number in configure.ac, except when it needed to be changed. As you've discovered, commit-by-commit changing of the revision number gets tedious very quickly.

IIRC, what I remember settling on was adding a file that had the version info as an EXTRA_DIST file (so it was bundled with the tarball). In order to make that file I had another file as a phony target which grabbed the revision info from the VCS (if it detected it was using one, opposed to being an extracted source tarball) and copied itself (or not, if there was no VCS) to the EXTRA_DIST file. No macro witchcraft was involved at all.

So if version is the EXTRA_DIST target, something like:

mydef_version=`cat version`
AC_DEFINE_UNQUOTED([VERSION_GIT],["$mydef_version"])

in configure.ac would set up a define for your C++ translation unit:

const char version_info[] = VERSION "." VERSION_GIT;

The EXTRA_DIST file could also be a self contained translation unit too that just has version info.

I was using rpmbuild on my CI server which requires a tarball to build instead of a checked-out repo, so basically the first stage of the build was basically autoreconf...; ./configure...; make dist; and the second stage was rpmbuild -ta tarball;.

Upvotes: 2

Related Questions