GZDoom 4.8.0 released
Moderator: GZDoom Developers
-
- Posts: 165
- Joined: Sun Feb 07, 2016 11:38 am
- Operating System Version (Optional): Windows 10
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
- Location: Ukraine
Re: GZDoom 4.8.0 released
I don't see this https://github.com/coelckers/gzdoom/com ... 7313b6dded in the list. Is it added to 4.8.0?
-
- Lead GZDoom+Raze Developer
- Posts: 49179
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 4.8.0 released
Yes, it is.
-
- Posts: 349
- Joined: Mon Feb 12, 2018 12:26 am
- Graphics Processor: Intel (Legacy GZDoom)
- Location: Australia
Re: GZDoom 4.8.0 released
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.
-
- Posts: 272
- Joined: Sat Dec 12, 2020 10:59 am
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Void Linux
- Graphics Processor: Intel (Modern GZDoom)
- Location: Independence, KS, USA
Re: GZDoom 4.8.0 released
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?fakemai wrote: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.
-
- Posts: 13782
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: GZDoom 4.8.0 released
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.
-
- Posts: 2166
- Joined: Mon Sep 05, 2011 8:50 pm
- Location: a place lol!
Re: GZDoom 4.8.0 released
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.
-
- Lead GZDoom+Raze Developer
- Posts: 49179
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 4.8.0 released
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.
-
- Posts: 272
- Joined: Sat Dec 12, 2020 10:59 am
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Void Linux
- Graphics Processor: Intel (Modern GZDoom)
- Location: Independence, KS, USA
Re: GZDoom 4.8.0 released
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.Rachael wrote: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.
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.
-
- Lead GZDoom+Raze Developer
- Posts: 49179
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 4.8.0 released
"-m" means you have uncommitted changes to at least one file in the repo.
-
- Posts: 272
- Joined: Sat Dec 12, 2020 10:59 am
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Void Linux
- Graphics Processor: Intel (Modern GZDoom)
- Location: Independence, KS, USA
Re: GZDoom 4.8.0 released
But then wouldn't '$ git reset --hard' undo whatever supposed uncommitted changes?Graf Zahl wrote:"-m" means you have uncommitted changes to at least one file in the repo.
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.
-
- Posts: 13782
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: GZDoom 4.8.0 released
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!)
-
- Posts: 272
- Joined: Sat Dec 12, 2020 10:59 am
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Void Linux
- Graphics Processor: Intel (Modern GZDoom)
- Location: Independence, KS, USA
Re: GZDoom 4.8.0 released
Just tried that it's still wanting to say "-m" at the end, even though git status reports nothing to commit source tree clean.Rachael wrote: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!)
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.
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"
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
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")
-
- Posts: 13782
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: GZDoom 4.8.0 released
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.
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.
-
- Posts: 272
- Joined: Sat Dec 12, 2020 10:59 am
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Void Linux
- Graphics Processor: Intel (Modern GZDoom)
- Location: Independence, KS, USA
Re: GZDoom 4.8.0 released
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.Rachael wrote: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.
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
-
- Posts: 13782
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: GZDoom 4.8.0 released
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.