Ticket #58 (closed enhancement: fixed)

Opened 11 years ago

Last modified 10 years ago

xuvtools: revision is not updated automatically

Reported by: ne704 [niko@… Owned by: ne704
Priority: minor Milestone:
Component: xuvtools Version:
Keywords: xuvtools, buildsystem Cc: developer@…

Description

the revision displayed when a user clicks on "about" is not updated automatically (file xuvtools_gui/src/consts.h), maybe this should be integrated in either SVN or the build-process, especially since this should be correct when determining if a bugreport is really created from the last version (so this should go into the logfiles as well)...

Change History

Changed 11 years ago by emmenlau

This is a long-standing request. Note that the problem is two-fold:

  • If the version number is changed for a release, it would be good if all source files would be recompiled to make sure that no code links against an older revision.
  • If code is commited, it would be good if the version number would be set accordingly automatically.

It seems these two requests do not play well together, as that would make a full recompile necessary after each commit. A workaround could be to set the version number automatically, but not to include the header in many places, so only these files need to be recompiled. Then it will depend on the distributor to make sure every release is done via a full recompile.

Changed 11 years ago by emmenlau

  • cc mario@…, aaron@… added; mario@… removed

Changed 10 years ago by ne704 [niko@…

  • keywords xuvtools, buildsystem added
  • status changed from new to assigned

ok, some news on the autoupdate-for-version-numbers issue...

there is now a possibility in r2975 to include an additional header file that is e.g. generated by the buildscript. this is completely non-intrusive in the sense that it does not have an impact on the previous way of compiling:

  • not having the extra header-file is the default and works as up to now, except explicitly specified otherwise on the (qmake) commandline
  • having the extra header-file does not affect the SVN, since it is supposed to be an autogenerated local file only (this way you don't have to mess with svn complaining about a changed or a new local file)
  • the file is used only if "CONSTS_GENERATED_H" is defined (to be done via "qmake DEFINE+=...")
  • in the latter case, the included header-file should set "CONSTS_H" to make sure the remaining entries of xuvtools_gui/src/consts.h will be ignored

This mechanism now gives us the possibility of adjusting the build-script to generate a header-file containing the relevant version information automatically. We even could think about directly generating the names from the location where the sources reside inside our repository, e.g. "XuvTools trunk (r2975)" for a trunk build and "XuvTools 1.5.1 (r3030)" for a build from a tag called "1.5.1" or similar.

Mario, I agree to your concerns that it would be nice to have a mechanism that makes sure a release build is recompiled completely from scratch, but I think (up to a certain point) this is the responsibility of the user. If desired, we could integrate a switch for building a release-package (that e.g. also calls some future windows setup package creation magic) that uses svn to make sure the code is up to date and has no local modifications or sparse files. We should keep this in mind for future discussion...

Next step is to integrate the required features into the buildscript. Any comments?

Changed 10 years ago by ne704 [niko@…

There is a first version of the adjusted buildscript available in r2976 (which is not in trunk by intention...).

Feel free to test it, I'll be happy to get feedback on it.

Cheers, Niko

Changed 10 years ago by ne704 [niko@…

So far, the code works fine for me on windows and I haven't receive any complaints.

I'd like to pimp it towards being able to figure out if the build comes from a clean svn-checkout or if there have been local modifications at build-time.

Other not yet implemented tasks:

  • port to linux/mac
  • merge with trunk

Changed 10 years ago by emmenlau

Just as a side-note, don't know if this is of value to you: "svnversion" is a *lot* slower than "svn info" on Windows. On Unix, both take seconds even for large projects. on Windows, "svnversion" can take several minutes where "svn info" takes seconds.

Changed 10 years ago by ne704 [niko@…

  • priority changed from trivial to minor
  • type changed from task to enhancement

Yet another task:

  • generate rcfile-information for windows-binaries

Mario, thanks for the hint. It's a good point to avoid svnversion here, but no need to change any code since I have used svn info ever since I started to adjust the script :)

Changed 10 years ago by ne704 [niko@…

One more task (and sorry for spamming you):

  • add documentation (and scripts) on how to get a clean and proper Intel build-environment in a cygwin-terminal to minimize the risk of someone messing up with those pity environment-variables

Changed 10 years ago by ne704 [niko@…

short reminder: my test on win32 failed, have to investigate this deeper...

Changed 10 years ago by ne704 [niko@…

added batch-files and a windows-shortcut to create a proper (intel) build-environment in a cygwin-rxvt-terminal (32 and 64 bit) in r3014.

NOTE, this batch-files rely mainly on three assumptions (though this can easily be adjusted):

  • your cygwin-installation resides in "C:\cygwin"
  • you have installed the rxvt-x11 package
  • the "LMBSOFT" environment-variables are set correctly

given those requirements are satisfied, you should be able to call the shortcut from any place since it uses the variables to locate paths. so you can just copy it to your desktop/start-menu/toolbar or whatever you like.

Changed 10 years ago by ne704 [niko@…

unlike stated above, the autorevision-stuff works on win32 as expected

Changed 10 years ago by ne704 [niko@…

  • cc niko@…, mario@…, aaron@… removed

Removing the others from CC since this task is basically completed, I just use the report for tracking the ToDo?-items.

ToDo list and status, "(S)tarted", "(C)ompleted", "(O)pen":

  1. (S) port to linux/mac
  2. (C) merge with trunk
  3. (S) generate rcfile-information for windows-binaries
  4. (S) add documentation (and scripts) on how to get a clean and proper Intel build-environment in a cygwin-terminal to minimize the risk of someone messing up with those pity environment-variables

Changed 10 years ago by emmenlau

  • cc developer@… added

Thanks for this. I made some changes that will help me use consts.h in more places in the code. Here is an idea how consts.h looks like now:

#define DEFINE_TO_STRING(x) // use this to access a define as a const char-array.

#define TARGET_ARCH "unknown"
#define COMPILER_VERSION "unknown"
#define SVN_BRANCHNAME "unknown"
#define SVN_REVISION "unknown"

#define XUVTOOLS_VERSION_MAJOR 0
#define XUVTOOLS_VERSION_MINOR 0
#define XUVTOOLS_VERSION_PATCH 0

There is no version-string anymore. You can use the header to generate the version string dynamically, i.e. like this:

std::string(DEFINE_TO_STRING(XUVTOOLS_VERSION_MAJOR)"."DEFINE_TO_STRING(XUVTOOLS_VERSION_MINOR)"."DEFINE_TO_STRING(XUVTOOLS_VERSION_PATCH)" (revision "SVN_REVISION")");

This might look awkward at first, but has multiple advantages, i.e. the single version numbers are available as integers, which are used to store the version number in the project file. I would also like to keep the consts.h header as general as possible, so it can be used for other projects as well. Therefore I added as few XuvTools?-specific defines as possible.

TODO list and status, "(S)tarted", "(C)ompleted", "(O)pen":

  1. (C) port to linux/mac
  2. (C) merge with trunk
  3. (S) generate rcfile-information for windows-binaries
  4. (S) add documentation (and scripts) on how to get a clean and proper Intel build-environment in a cygwin-terminal to minimize the risk of someone messing up with those pity environment-variables

Changed 10 years ago by ne704 [niko@…

  • status changed from assigned to closed
  • resolution set to fixed

Closing this bug as fixed since the buildscript has proven pretty robust for this task.

Followup-tickets for the remaining two tasks can be found at #129 and #130.

Note: See TracTickets for help on using tickets.