On Sun, Oct 07, 2007 at 11:09:24AM +0200, Ulf Jordan wrote:
However, I believe we don't want the superiotool version to increase just because there are other commits in the v2 tree, so the example needs adapting by adding -c to svnversion.
That's no problem IMO. The important thing is that the version _does_ increase if we change superiotool files. If it also increases upon other changes, well, we can live with that...
Attached is a patch that:
- derives the superiotool version number from the latest committed change
to superiotool files (NOT the latest svn up of the superiotool directory)
Hm, isn't that wrong? We want to know the extact version from which the binary was built, _not_ the most current version in the repository at the time it was built...
- strips away extra information from svnversion, to arrive at a single
version number like 2828 instead of 2814:2828M ("this build is made up of files with latest modification in rev 2814 to 2828 plus local modifications").
Hm, maybe that would even be a good thing? We could tell from that output that a user used a modified version and ask for a diff...
- does not recurse down into subdirectories or svn:externals (there are no
such things in superiotool for the moment)
Yep, not needed.
does all the work in determining the version number at build time
depends on GNU make features (although it could be rewritten more
portably using a version.h file instead, like my previous patch)
Maybe we could do this later, but it's fine for now. GNU Make should be available almost everywhere.
This approach could easily be combined with a traditional version number from a #define in superiotool.h, as Robinson pointed out.
Not needed and not useful. We don't want to confuse people with _two_ versioning systems.
Index: Makefile
--- Makefile (revision 2828) +++ Makefile (working copy) @@ -24,14 +24,19 @@ INSTALL = /usr/bin/install PREFIX = /usr/local
+SVNDEF := -D'SUPERIOTOOL_VERSION="$(shell svnversion -cn . \
| sed -e "s/.*://" -e "s/\([0-9]*\).*/\1/")"'
Please add a comment here which explains what the contents of the variable will be (svn rev of latest commit etc...), how it works, etc.
Personally, I like this approach. Either this one, or the one from my patch (which doesn't require svn at build-time). That's a small issue though, distributors can easily work around it by patching the Makefile.
If nobody complains, let's commit this ASAP so we have a working version in the repository. We can still continue the discussions to improve the version handling later, if necessary.
Uwe.