aboutsummaryrefslogtreecommitdiff
path: root/base
diff options
context:
space:
mode:
authorMax Horn2006-04-29 12:38:28 +0000
committerMax Horn2006-04-29 12:38:28 +0000
commita427a14ebe01e502c801ad375abc78dfa1593427 (patch)
tree6ed1d6bdcd694303b8240b3d6536da9fe789046e /base
parentffe434a9494b67d8b92d660a2eeb24a1e571d9f8 (diff)
downloadscummvm-rg350-a427a14ebe01e502c801ad375abc78dfa1593427.tar.gz
scummvm-rg350-a427a14ebe01e502c801ad375abc78dfa1593427.tar.bz2
scummvm-rg350-a427a14ebe01e502c801ad375abc78dfa1593427.zip
Updated the common on why we would like to display the SVN rev as part of the ScummVM version string, and why this is non-trivial
svn-id: r22217
Diffstat (limited to 'base')
-rw-r--r--base/version.cpp30
1 files changed, 10 insertions, 20 deletions
diff --git a/base/version.cpp b/base/version.cpp
index 8bd31fc9d0..cdc949b60f 100644
--- a/base/version.cpp
+++ b/base/version.cpp
@@ -33,7 +33,7 @@
* Note: it would be very nice if we could instead of (or in addition to) the
* build date present a date which corresponds to the date our source files
* were last changed. To understand the difference, imagine that a user
- * makes a checkout of CVS on January 1, then after a week compiles it
+ * makes a checkout on January 1, then after a week compiles it
* (e.g. after doing a 'make clean'). The build date then will say January 8
* even though the files were last changed on January 1.
*
@@ -42,28 +42,18 @@
* It's clear that such a "last changed" date would be much more useful to us
* for feedback purposes. After all, when somebody files a bug report, we
* don't care about the build date, we want to know which date their checkout
- * was made. This is even more important now since anon CVS lags a few
- * days behind developer CVS.
+ * was made.
*
* So, how could we implement this? At least on unix systems, a special script
- * could do it. Basically, that script would run over all .cpp/.h files and
- * parse the CVS 'Header' keyword we have in our file headers.
- * That line contains a date/time in GMT. Now, the script just has to collect
- * all these times and find the latest. This time then would be inserted into
- * a header file or so (common/date.h ?) which engine.cpp then could
- * include and put into a global variable analog to gScummVMBuildDate.
+ * could do it. Basically, that script could parse the output of "svn info" to
+ * determine the revision of the checkout, and insert that information somehow
+ * into the build process (e.g. by generating a tiny header file, analog to
+ * internal_version.h, maybe called svn_rev.h or so.
*
- * Drawback: scanning all source/header files will be rather slow. Also, this
- * only works on systems which can run powerful enough scripts (so I guess
- * Visual C++ would be out of the game here? don't know VC enough to be sure).
- *
- * Another approach would be to somehow get CVS to update a global file
- * (e.g. LAST_CHANGED) whenever any checkins are made. That would be
- * faster and work w/o much "logic" on the client side, in particular no
- * scripts have to be run. The problem with this is that I am not even
- * sure it's actually possible! Modifying files during commit time is trivial
- * to setup, but I have no idea if/how one can also change files which are not
- * currently being commit'ed.
+ * Drawback: This only works on systems which can run suitable scripts as part
+ * of the build proces (so I guess Visual C++ would be out of the game here?
+ * I don't know VC enough to be sure). And of course it must be robust enough
+ * to properly work in exports (i.e. release tar balls etc.).
*/
const char *gScummVMVersion = SCUMMVM_VERSION;
const char *gScummVMBuildDate = __DATE__ " " __TIME__;