GZDoom 4.8.0 released

[theleo_ua]

I don't see this https://github.com/coelckers/gzdoom/com ... 7313b6dded in the list. Is it added to 4.8.0?

[Graf Zahl]

Yes, it is.

[fakemai]

The .deb exists in the Github's releases list, and it SAYS it's g4.8.0 in the console while I'm using it.

[KynikossDragonn]

The .deb exists in the Github's releases list, and it SAYS it's g4.8.0 in the console while I'm using it.

Mine has a -m at the end for some reason: "g4.8.0-m" even though when I had compiled 4.7.1 it just says "g4.7.1", I wonder why?

[Rachael]

Means whoever prepared the binary had to make changes before dispatching the build process. "-m" means the build is dirty and altered from its original state, according to git.

[Abba Zabba]

Will this Raze style HUD scaling be the exclusive going forward, or will the old settings be retained? And in addition to that, is it intentional for the options menu (along with all its submenus) to display at a tiny 1x setting, regardless of the UI scale setting you have selected? Also worth mentioning that the automap keeps adjusting its own scale setting everytime it's opened, making it jitter for a split second. If you think that's enough to warrant a bug post, then let me know.

[Graf Zahl]

The option menu is not affected by the UI scale. It cannot be because it needs a certain minimum width to display correctly, so enlarging it won't work. No idea about the automap, this does not happen for me.

[KynikossDragonn]

Means whoever prepared the binary had to make changes before dispatching the build process. "-m" means the build is dirty and altered from its original state, according to git.

That... doesn't really make any sense, I'm not modifying any of the files, the build happens in a out of tree folder just like the wiki says.

What "changes" do you mean? Changes to the in-tree files? Or changes to the generated CMake build? Because the only thing happening to the tree is checking out the g4.8.0 tag. The only thing happening to the CMake files is me going through with the CMake GUI and setting everything needed for a Release build and making sure it knows where to find ZMusic. (I don't install ZMusic system wide)

If it's because I change my CMake options around, I have been doing the same thing for g4.7.0 and g4.7.1 and it never put a "-m" at the end.

I'm using Git 2.36.1 if that has anything to do with it.

[Graf Zahl]

"-m" means you have uncommitted changes to at least one file in the repo.

[KynikossDragonn]

"-m" means you have uncommitted changes to at least one file in the repo.

But then wouldn't '$ git reset --hard' undo whatever supposed uncommitted changes?

It says "HEAD is now at 08e46766a - this is 4.8.0" after I do the detatch checkout and the reset hard. I really don't understand what's going on here... Nothing should be being modified anywhere except in the place where the compile actually happens inside of.

[Rachael]

You can try git reset --hard and then git clean -f -d -x to get your checkout into pristine condition. The second command will remove any loose files, including the build folder. (note that these changes are done permanently without confirmation!)

[KynikossDragonn]

You can try git reset --hard and then git clean -f -d -x to get your checkout into pristine condition. The second command will remove any loose files, including the build folder. (note that these changes are done permanently without confirmation!)

Just tried that it's still wanting to say "-m" at the end, even though git status reports nothing to commit source tree clean.

I just now noticed this during the build process:

Code: Select all

[155/684] cd /tmp/gzdoom && /usr/bin/c...ion/UpdateRevision.cmake src/gitinfo.h src/gitinfo.h updated to commit g4.8.0-m.

contents of said file:

Code: Select all

// 08e46766ad442037a0129362b0e7ae7bcd1e8080
//
// This file was automatically generated by the
// updaterevision tool. Do not edit by hand.

#define GIT_DESCRIPTION "g4.8.0-m"
#define GIT_HASH "08e46766ad442037a0129362b0e7ae7bcd1e8080"
#define GIT_TIME "2022-06-06 17:14:47 +0200"

This is even when I made the build directory outside of the directory the git clone is. Just so that there's nothing out of tree and absolutely nothing should be changed whatsoever.

So I'm just going to list off every single step I took as of right now:

• $ cd /tmp
• $ git clone 'https://github.com/coelckers/gzdoom.git'
• $ cd ./gzdoom
• $ git config --local --add remote.origin.fetch +refs/tags/*:refs/tags/*
• $ git pull
• $ git checkout --detach refs/tags/g4.8.0
• $ git reset --hard
• $ git clean -f -d -x
• $ cd ..
• $ git clone 'https://github.com/coelckers/ZMusic.git'
• $ cp -p ~/gzdoom/libzmusic.so.1 ./
• $ mkdir gzdoom_build
• $ mkdir gzdoom_install
• Run CMakeGUI and configure accordingly (pointing it to libzmusic, setting Release, install prefix to /tmp/gzdoom_install, CMAKE_INSTALL_RPATH $ORIGIN etc)
• $ cd ./gzdoom
• $ git reset --hard
• $ git clean -f -d -x
• $ cd ../gzdoom_build
• $ cmake --build . --target install

EDIT:
So I did a git status after building and noticed this just now:

Code: Select all

$ git status
HEAD detached at g4.8.0
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   libraries/discordrpc/src/discord_register_linux.cpp
	modified:   libraries/discordrpc/src/serialization.h

no changes added to commit (use "git add" and/or "git commit -a")

... would THAT be why I'm getting a "-m"? Nothing in the CMakeGUI mentions discordrpc.

[Rachael]

No - something's wigging out and detecting a change in your file system.

If you're on a non-standard file system format for your OS, try mounting an ext4 partition (for Linux), HFS+ for Mac, NTFS for Windows, or ZFS for the BSD's, and see if the problem still persists after moving the source tree to that partition.

[KynikossDragonn]

No - something's wigging out and detecting a change in your file system.

If you're on a non-standard file system format for your OS, try mounting an ext4 partition (for Linux), HFS+ for Mac, NTFS for Windows, or ZFS for the BSD's, and see if the problem still persists after moving the source tree to that partition.

My main filesystem is ext4, /tmp is tmpfs. I'm on a SSD that I'm very conscious about excessive writes so I try to build things from source entirely within RAM. This was never a problem in the past, only with g4.8.0 and only with those discordrpc files.

I just moved everything over to my main filesystem, already started the build process, already noticed it putting g4.8.0-m in the terminal output so, moving everything to my filesystem made no change.

I even just did a git status while the build is underway and it's reporting the same exact thing. discord_register_linux.cpp and serialization.h reported being modified.

EDIT: I changed to using Unix Makefiles and,

Code: Select all

$ strings ./gzdoom | grep g4.8
g4.8.0

but git status still complains about those two files after the build. So the build process IS modifying stuff in the source tree, but apparently if you try to use Ninja it ends up running whatever to get the git info to return that the tree is modified rather than running it before the tree is modified... either way the tree is clearly being modified regardless!

[Rachael]

The problem might be ninja then. The only file that should ever get changed outside of the build folder is src/gitinfo.h - which is autogenerated by running the "updaterevision" during compile. That is not tracked by git, so it shouldn't be affecting things whatsoever, unless ninja is forcing the file to be added to the tree.