 |
As I recall, for the revision to work you must build the matching ExtLibs.dll |
 |
This is caused by: http://forums.thedarkmod.com/topic/18841-disable-svnkeywords/?hl=svnversion#entry408462 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? |
|
|
Windows 7 Tortoise SVN |
|
|
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: https://stackoverflow.com/a/9874961/556899 |
|
|
"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. |
|
|
Reinstalled TSVN. Enabled command line client tools. Ran gen_svnversion.cmd. 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... |
- Anonymous
