Add source revision number to version information

[willu.mailingLists@…]

The attached patch adds the current subversion revision to the data printed out on startup for mythfrontend and mythbackend.

A call to svnversion is added to the configure script. Configure generates a file, libs/libmyth/vers.cpp, which adds a new global string in libmyth containing the revision information of the source. If there are no .svn directories then you get a default string with the release number.

I didn't use a header file as I didn't want too much to have to be recompiled every time the revision changes (which is frequently to say the least). As written, one file will have to be recompiled, libraries and programs will only need to be re-linked.

As well as the attached patch, you probably also want to add libs/libmyth/vers.cpp to the svn:ignores property of libs/libmyth/.

This patch might be changed by putting the generation of vers.cpp into the Makefile rather than having it happen at compile time. This would require qmake wizardry, and I didn't think it was worth it.

[willu.mailingLists@…]

a svn diff of the changes

[Isaac Richards]

This won't be accurate enough, as people won't run configure before every build.

[willu.mailingLists@…]

Okie - I've made the qmake changes so that it is run at make time rather than configure time

[willu.mailingLists@…]

patch that has the version detected at make time rather than configure time

[mythtv@…]

Shell script to generate version (meant to be placed in libs/libmyth). Replace .commands from willu's with: sh ./generate-vers-cpp.sh "$$VERSION" to use this instead. This uses a slightly different format than he does (gives VERSION and svnversion). Using a shell script increases flexibility and, I believe, maintainability.

[Nigel]

I think something like this is a great idea to reduce future support issues. Isaac, I hope we can eventially ban any bug reports which do not include an exhaustive, Subversion based, revision number!
My thoughts:

1.Having the generated version stuff in libs/libmyth is logical, but I am concerned that this will mean some changes are not documented. e.g. someone does a svn update in programs/mythbackend, but doesn't remake in libs. My thought is to have the makefile of every directory that builds a program to generate and link new version stuff each time we make

2.The shell script added by Hal may be a better way of doing it, but I disagree with using svn info, because its inaccuracy:
% cd Programming/MythTV/latest
% svn info . 2>/dev/null | grep Revision | awk '{print $2}'
8469
% svnversion .
8469:8603M
does not make up for any slight speed difference

3.Ideally, the file revisions for everything would be itemised by using the --version flag. e.g.
mythfrontend --version
API: 0.18.1.20050510-1
mythfrontend source: 8317M
libmyth source: 8605M
libmythtv source: 8523M
libmythavformat source: 8605
libmythavcodec source: 8605
I suspect this wouldn't actually add much to bug reports, though

4.Another good thing would be listing a separate version for each module. Maybe --version could try a practice load of all modules with an option to get them to print out a version? Too hard for now, though.

I will play around with creating a new top-level qmake include, version.pro. Isaac/Daniel?, if this sounds like a good way to go, reassign this to me.

[Nigel]

Simple qmake rules to include in any dir with a main.cpp

[Nigel]

Patches to use new version.pro

[Nigel]

OK, I have something simple working:

% svn diff >mythtv-version.diff
% mythfrontend --version
Library API version: 0.19.20051208-1
Source code version: 8614M
Options compiled in:
 release using_dvdnav using_frontend

To do it the other (version.cpp) way, uncomment the relevant lines in version.pro, and do this in main.cpp:

        else if (!strcmp(a.argv()[argpos],"--version"))
        {
            extern const char *myth_source_version;
            cout << "Library API version: " << MYTH_BINARY_VERSION << endl;
            cout << "Source code version: " << myth_source_version << endl;
#ifdef MYTH_BUILD_CONFIG

Anyway, I think this is a good idea, but I will wait for feedback from others before commiting

[Isaac Richards]

Nigel, I think a per-directory version number is going to be rarely used. The vast majority of the time people do a full-module update/checkout, so I think this is just going to be confusing (to developers) if it starts reporting lots of different version numbers for each and every bit.. Just me, but I think the original 'limited to libmyth' way is a bit easier.

Either way, though, please just make sure it works for releases and people without svn installed, and feel free to commit either method.

[willu.mailingLists@…]

Hi,

I don't want to have too much discussion in the ticket :), but the 'original' way was only partially 'limited to libmyth'. The version number generated was for 2 directories above libmyth - i.e. the mythtv subtree for a normal working checkout. It was only 'limited to libmyth' in the sense that there was only one string for the whole of mythtv, and it was stored in libmyth, so if you recompiled a program somewhere else and then used it with the wrong dynamic library, then you would get the wrong version string. But in that case you have other problems.

Be well,

Will :-}

[Nigel]

I think I have got this right. If there is no .svn directory (e.g. a source tarball), svnversion says "exported." If no svnversion binary, the version will be "Unknown." I have only applied this to the frontend and backend for now.

[Nigel]

(In [8666]) Subversion revision information now printed out in response to --version for the front/backend. See #885

[Nigel]

(In [8667]) Try to get bug reporters to use new improved --version arg. See #885

[Nigel]

A few small problems. 1) It isn't actually updating the version after the initial qmake (which sets the version in the makefile), and 2) Make install also regenerates the file, which can cause problems because the permissions, compiler and libs are different.
These could be fixed via make trickery, but it will be tidier to use a separate shell script?

[justifiably@…]

The permissions problem for install is a nuisance for me, because I have the sources on an NFS mount and compile as non-root user, then install as root on each machine. Without root squash the root install cannot write to the source directory. I'm attaching a patch to version.pro which avoids changing version.cpp if it hasn't changed, BUT it turns out that the svnversion command wants to write to the repository to do its calculations! Does anyone know if there is a way to make it write temporary files somewhere else?

[Nigel]

I don't have a workaround for the make install root permissions problem yet. A "reduce un-necessary work" patch is now in, but what I really need to do is eliminate the version target for make install.
Also don't know what to do on Windows. Assume that the developer has a Unix-like environment? Go back to the qmake-based stuff?

[Nigel]

The "readonly mountpoint" problem is hard to fix. The subversion client programs use a library (libsvn_wc) that controls access to the "working copy", and this controls temp file creation, et c. Sadly, that library has no overrides for that tempfile creation, and reasonably expects svn programs to be able to write under their own .svn directory.
Someone could petition the authors to change that, but I don't think it is worth it.
I suspect this is not as much of a problem now. If a source file has changed, the first make should do the writing of the file .svn/tmp/filename.tmp, and any subsequent "sudo make install"s will not have to, because the svn "working copy" database will be updated.
I am now going to close this ticket. It has been open for too long, I have hearn no complaints about the version stuff, and I don't care about Windows builds and svnversion (for now).