Linux tar.xz builds abandoned

[sacarias]

I would like to ask what happened to these builds, which are no longer updated for close to a year already.

Or if maintainer just quit for good, I'd like to ask who it was and how did he made the builds to try myself, because the ZDoom wiki for this is long outdated and, given all the libraries included in the tar.xz builds, it seems ze used a different process.

[Guest]

Those builds were discontinued due to compatibility issues with various Linux distributions and conflicts between included system libraries and those on target systems. The original maintainer used the included auto-build-linux.sh script which no longer works due to lack of maintenance and vcpkg updates.

[sacarias]

Thanks very much for your answer.

With vcpkg updates, do you mean lack of them as well?

Does this mean the only way to build for Linux systems is again the one at ZDoom wiki, even though it still needs some fixes?

[Guest]

vcpkg is a self updating software and with gzdoom it self-updated a few times to cause breakage in the compiling process, so its use was discontinued. The Linux build script was not fixed since.

To build on a Debian-based Linux it should be as simple as this:

[code]
sudo apt-get install libsdl2-dev libopenal libvpx-dev libbz2-dev git cmake build-essential
git clone https://github.com/zdoom/zmusic
cd zmusic
mkdir build
cmake .. -DCMAKE_BUILD_TYPE=Release
make -j $(nproc)
sudo make install
cd ../..
git clone https://github.com/zdoom/gzdoom
cd gzdoom
mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make -j $(nproc)
[/code]

If you build on any other Linux distro everything should be exactly the same except for the first line for the package grab. You will have to research what package equivalents are and change the command to match your distro's package manager. Not all distros can build and run GZDoom, but by far the majority can and the ones that build for themselves will typically run it out of the box without issue.

[axredneck]

...
sudo make install
...

It's a bad practice in case of modern distros.

[sacarias]

Thanks very much again.
It's very similar to the process I followed last time I tried (many months ago), in a Debian box.

Some doubts then:
---Aren't you missing all the gl Mesa / Gtk development libraries? Last time I tried they were not pulled automatically with the other dependencies.
---Couldn't libbz2-dev actually be statically built by GZDoom itself?
---Is fluidsynth no longer needed overall?
---Last time I tried cmake complied about webp being missing, even when libwebp-dev was already installed
---For make, should I use number of CPU cores, or threads?
---git clone clones current state of source at the moment; how can I clone release's source? For example, git clone release 4.13.2

Thanks again.

[Guest]

> Aren't you missing all the gl Mesa / Gtk development libraries? Last time I tried they were not pulled automatically with the other dependencies.
They should not be necessary. If they are, then the build has never failed for me without them. It might be a distro thing.

> Couldn't libbz2-dev actually be statically built by GZDoom itself?
It's supposed to be but for some reason mine didn't detect it so I added it to the package list.

> Is fluidsynth no longer needed overall?
It's embedded into zmusic directly

> Last time I tried cmake complied about webp being missing, even when libwebp-dev was already installed
I don't know. The instructions I gave you work for most from-scratch installs.

> For make, should I use number of CPU cores, or threads?
$(nproc) already handles that

> git clone clones current state of source at the moment; how can I clone release's source? For example, git clone release 4.13.2
After you clone you can type "git checkout g<version>" i.e. "git checkout g4.13.2". If your repository is out of date you can use "git fetch --all" and try again.