Opened 14 years ago

Closed 13 years ago

#885 closed patch (fixed)

Add source revision number to version information

Reported by: willu.mailingLists@… Owned by: Nigel
Priority: minor Milestone: 0.20
Component: mythtv Version: head
Severity: low Keywords:
Cc: Ticket locked: no

Description

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.

Attachments (6)

myth-version.diff (5.0 KB) - added by willu.mailingLists@… 14 years ago.
a svn diff of the changes
myth-version.2.diff (4.7 KB) - added by willu.mailingLists@… 14 years ago.
patch that has the version detected at make time rather than configure time
generate-vers-cpp.sh (960 bytes) - added by mythtv@… 14 years ago.
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.
version.pro (709 bytes) - added by Nigel 14 years ago.
Simple qmake rules to include in any dir with a main.cpp
mythtv-version.diff (1.0 KB) - added by Nigel 14 years ago.
Patches to use new version.pro
version.patch (920 bytes) - added by justifiably@… 13 years ago.

Download all attachments as: .zip

Change History (23)

Changed 14 years ago by willu.mailingLists@…

Attachment: myth-version.diff added

a svn diff of the changes

comment:1 Changed 14 years ago by Isaac Richards

Resolution: wontfix
Status: newclosed

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

comment:2 Changed 14 years ago by willu.mailingLists@…

Resolution: wontfix
Status: closedreopened

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

Changed 14 years ago by willu.mailingLists@…

Attachment: myth-version.2.diff added

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

Changed 14 years ago by mythtv@…

Attachment: generate-vers-cpp.sh added

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.

comment:3 Changed 14 years ago by anonymous

Cc: mythtv@… added

comment:4 Changed 14 years ago by 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.

Changed 14 years ago by Nigel

Attachment: version.pro added

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

Changed 14 years ago by Nigel

Attachment: mythtv-version.diff added

Patches to use new version.pro

comment:5 Changed 14 years ago by 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

comment:6 Changed 14 years ago by 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.

comment:7 Changed 14 years ago by 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 :-}

comment:8 Changed 13 years ago by danielk

Owner: changed from Isaac Richards to Nigel
Status: reopenednew
Version: head

comment:9 Changed 13 years ago by Nigel

Status: newassigned

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.

comment:10 Changed 13 years ago by Nigel

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

comment:11 Changed 13 years ago by Nigel

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

comment:12 Changed 13 years ago by 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?

comment:13 Changed 13 years ago by 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?

Changed 13 years ago by justifiably@…

Attachment: version.patch added

comment:14 Changed 13 years ago by 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?

comment:15 Changed 13 years ago by anonymous

Cc: mythtv@… removed

comment:16 Changed 13 years ago by Isaac Richards

Milestone: 0.190.20

comment:17 Changed 13 years ago by Nigel

Resolution: fixed
Status: assignedclosed

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).

Note: See TracTickets for help on using tickets.