View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004679||The Dark Mod||Coding||public||20.11.2017 22:04||22.11.2017 17:15|
|Target Version||TDM 2.06||Fixed in Version||TDM 2.06|
|Summary||0004679: Highest revision number is no longer available|
|Description||The routine GetHighestRevision() provides the highest SVN revision number for files used in a particular build.|
This number is printed on the console when you pull it down, and is also used in savegame/loadgame checking.
The number comes from running the pre-build program gen_svnversion.cmd (Windows) (and something similar in the Linux scons build). I believe this program reads the svn version number comments in the source files, looking for the highest version number. It then stores that number in string form in the file svnversion.h as the define SVN_WORKING_COPY_VERSION.
At some point during 2.06 development, the svn version number comments were stripped from the source files, rendering this process useless. I don't know the effect this has on the savegame/loadgame version-checking code, but the version number painted on the console is now "0".
|Additional Information||Is there a way to get back the svn version number of the build, or do we have to:|
a - strip the version number from the command line
b - render the savegame/loadgame version checking irrelevant in the code
|Tags||No tags attached.|
|As I recall, for the revision to work you must build the matching ExtLibs.dll|
This is caused by:
Not related to ExtLibs.
Please write which platform do you have on the machine which does not detect revision, and which SVN client do you have.
Also try to run "svnversion" in SVN root directory in windows console (or Far Manager). It must print you the current revision number (7286 in my case). If it does not do this, try to make it work. svnversion is the standard command of SVN.
If svnversion works, then you should try to run explicitly gen_svnversion.cmd and check if idlib/svnversion.h is correct after that. If on Linux, then you should run scons build: it generates svnversion as the very first step and prints "Inserted SVN revision number into svnversion.h".
Of course, the revision number is still necessary and useful.
But it is no longer coming from the source code files, it comes from SVN client directly now using svnversion.
|And the SVN root directory is where?|
|I looked through the project properties and I don't see where svnversion is run as a pre-build command.|
It is run as pre-build event of idLib:
cd $(ProjectDir) call gen_svnversion.cmd
SVN root directory is the directory to which you checked out the coding SVN. The one where gen_svnversion.cmd is located, and where MSVC solution is located.
Did you try to run svnversion in console?
Did you try to run gen_svnversion.cmd manually?
Ok, how long ago did you install your TortoiseSVN client?
Did you enable command line tools during install? Can you write "svn up" in console so that Windows knows what the hell "svn" is?
Consider reinstalling TortoiseSVN, and make sure you enable command line client tools as shown here:
"It is run as pre-build event of idLib:"
Eg. Isn't idLib now located in ExtLibs.dll?
Of course not.
ExtLibs is for external dependencies (like OpenAL, FFmpeg), and idLib is the inherent part of TDM engine. It is a static library linked into the engine executable.
And idLib contains the RevisionTracker of TDM, hence the custom build step is put on it, not on the engine.
Enabled command line client tools.
svnversion.h now shows the latest rev.
However, building TheDarkModTools claims it can no longer find ExtLibs.dll.
That is some progress =)
Did you try full solution rebuild?
Do you see ExtLibs.dll in darkmod_src or in darkmod directory? If yes, perhaps delete it and check if build creates it again.
Is anything different if you run TheDarkMod.exe manually from darkmod directory instead of from debugger? Do you run TheDarkMod.exe from darkmod directory?
Maybe last build failed for some reason?
To be honest, I have no idea how the fact that it does not find ExtLibs.dll can be caused by SVN client change. It should some generic "something did not get built/updated/created/run" issue.
I rebuilt the SVN binaries (clean, build) and the build had no problem finding ExtLibs*, but now I'm getting this fatal error for the Win32 build:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\atlmfc\include\afx.h(24): fatal error C1189: #error : Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD[d]
The 64-bit build completed properly.
|Using full solution rebuild in the 2.06 source build cleared the ExtLibs* problem, but I'm seeing the same Win32 fatal error as in the SVN source build.|
That's MayaImport project.
It does not build now. And it is not included in 64-bit build.
Anyway, the original problem is gone.
Should we add a GUI message which pops on startup in case SVN version is not available? Although it won't work if you had svnversion working on your local copy, and then reinstalled SVN and it stopped working.
After running the 32- and 64-bit linux builds, svnversion.h--properly filled in during the Windows builds--gets cleared.
Problem in SConstruct file?
Just the same: try running svnversion in terminal and see if it prints the revision number. Perhaps you have to install svn or svnversion package.
Also you can try to run:
sed "s/\!SVNVERSION\!/$(svnversion)/g" idlib/svnversion_template.h >idlib/svnversion.h
in the root directory of coding SVN.
Installed subversion on the linux guest box.
svnversion.h is now correctly filled in after both linux builds.
Thanks for the help!
Sorry for trouble!
Anyway, I'd like to repeat my question:
Should we add a GUI message which pops on startup in case SVN version is not available?
Anyone can easily forget to install something from SVN and produce binaries which don't know SVN version. Putting such binaries into another SVN is not good, putting them into release package may be disastrous...
|20.11.2017 22:04||grayman||New Issue|
|20.11.2017 22:04||grayman||Status||new => assigned|
|20.11.2017 22:04||grayman||Assigned To||=> stgatilov|
|20.11.2017 22:34||nbohr1more||Note Added: 0009648|
|21.11.2017 02:22||stgatilov||Note Added: 0009649|
|21.11.2017 02:24||stgatilov||Note Added: 0009650|
|21.11.2017 13:19||grayman||Note Added: 0009653|
|21.11.2017 13:20||grayman||Note Added: 0009654|
|21.11.2017 13:22||grayman||Note Added: 0009655|
|21.11.2017 15:20||stgatilov||Note Added: 0009656|
|21.11.2017 15:23||stgatilov||Note Added: 0009657|
|21.11.2017 15:49||nbohr1more||Note Added: 0009658|
|21.11.2017 15:55||stgatilov||Note Added: 0009659|
|21.11.2017 15:56||stgatilov||Note Edited: 0009659|
|21.11.2017 16:39||grayman||Note Added: 0009660|
|21.11.2017 17:09||stgatilov||Note Added: 0009662|
|22.11.2017 02:11||grayman||Note Added: 0009666|
|22.11.2017 02:16||grayman||Note Added: 0009667|
|22.11.2017 02:23||stgatilov||Note Added: 0009668|
|22.11.2017 02:25||stgatilov||Note Added: 0009669|
|22.11.2017 02:25||grayman||Note Added: 0009670|
|22.11.2017 04:01||stgatilov||Note Added: 0009671|
|22.11.2017 15:06||grayman||Note Added: 0009674|
|22.11.2017 15:08||grayman||Status||assigned => resolved|
|22.11.2017 15:08||grayman||Resolution||open => fixed|
|22.11.2017 15:08||grayman||Fixed in Version||=> TDM 2.06|
|22.11.2017 17:15||stgatilov||Note Added: 0009678|