Print engine name/version on startup

[AFADoomer]

When a bug is reported, the bug reporter is almost always asked to upload a log file.

Can the engine name and version number be printed on startup so that they would be automatically included in this log file, in order to eliminate repeatedly re-asking what version and engine is being used?

[Voros]

I support this.

[Graf Zahl]

Done.

[XxMiltenXx]

Regarding this version number: How is it updated?

I compile the GZDoom source on my own, however my version number never gets updated.

So even if I pull the latest commits, my version number is still: GZDoom 2.5pre-1128-g4c177e8. This is probably the version number when I set it up to compile it on my own.

How can I fix that? I update the source like this:

Code: Select all

cd\
cd gzdoom
cd src
git pull origin master

[Rachael]

That is the correct way. Are you getting the resulting executable from the correct location?

[XxMiltenXx]

Yes, the release files are in "C:\gzdoom\build64\Release".

It is built like this:

Code: Select all

cd\
cd gzdoom
cd build64
cmake -G "Visual Studio 14 2015 Win64" -T "v140_xp" -DCMAKE_BUILD_TYPE=RELEASE C:\gzdoom\src -D "OPENAL_INCLUDE_DIR=C:\Compiling\openal-soft-1.17.2-bin\include\AL" -D "OPENAL_LIBRARY=C:\Compiling\openal-soft-1.17.2-bin\libs\Win64\OpenAL32.lib"
msbuild.exe gzdoom.sln /t:Build /p:Configuration=Release

I can tell they are newly compiled from the date and that I have the newest features.
However the version number doesn't get updated and stays the one I have written earlier.

[Rachael]

That's indicative of the "updaterevision" subproject not executing, or not executing properly. Unfortunately, I do not know what could be wrong here, but just for testing sake open the Visual Studio IDE to your project, and select "updaterevision" and click "rebuild" - then do a simple "compile" (or full rebuild of the entire thing, if you prefer, but that should not be necessary) - does that update the version string?

Another thing that might be worth trying is compile (open Visual Studio, even) as administrator. If that updates the numbers correctly, then that means gitrevision.h was created by an administrator and it is not updateable by the restricted privileges of Windows' user account control system. Deleting the file as administrator and then compiling the project again as a restricted user should fix this issue, provided the folders themselves are not in the same state. (Or, alternatively, if you feel comfortable with the permission property pages, simply granting your personal account full access to the entire folder and its contents)

[_mental_]

Either git.exe is not available (i.e. its location is not in search paths) or tags were not fetched from remote repository.
In the first case edit your PATH environment variable to include path to directory with Git executable.
In the second case you can do:

Code: Select all

git fetch --all --tags

Pull should grab and update tags by default but this option can be turned off.

[XxMiltenXx]

Neither nor did help. I tried it as administrator and granting myself account full access to the folder and rebuilding the updaterevision.

The only thing that worked for now was making a hard reset of the folder:

Code: Select all

git fetch --all
git reset --hard origin/master
git pull origin master

The version number is now updated to
g3.2pre-462-g2375823

Will see if it stays updated now. Thanks, if it still doens't update I'll post it here again.

[Rachael]

Next time we do an update, I'd like to know if _mental_'s suggestion worked, as well.

[_mental_]

I assumed that you don't have local changes or 'detached head' state. If hard reset did the trick then you actually had that outdated version all the time. Most likely pulls were failing because git cannot update locally modified file(s).

[XxMiltenXx]

I assumed that you don't have local changes or 'detached head' state. If hard reset did the trick then you actually had that outdated version all the time. Most likely pulls were failing because git cannot update locally modified file(s).

Neither nor was the case. I didn't make any local changes (at least not intentionally), nor was I informed about a 'detached head' state and also pulls didn't fail. I did set it up wrongly before and I always had merging errors, because I was merging it with my local repository. But then I made a completely new folder (the current one) and only started pulling it, instead of merging it with the local repository.

I guess I did something wrong unintentionally, because now after the hard reset, even when I pull it like I described above, the version is now properly updated. So thanks for your help and that I was able to find a solution.