GZDoom 4.9.0 for ARM64 Windows (experimental)

[Graf Zahl]

You mean the same way as you did for PrBoom+? I think that would be a lot better than what we have now - and we could even get rid of some of the source distributions. I'd really like to move to libjpeg-turbo entirely and forget about the stripped down source of that old JPEG library we have right now. Then it would also be a lot easier to add new depenencies.

[_mental_]

Yes, it can be similar to PrBoom+ dependencies. Alternative solution is to use a dedicated Git repository for this purpose to simplify tracking of changes, and to keep build scripts, instructions, etc.

[Rachael]

I think that is most ideal - the script can be set to do a shallow checkout of said repo (if it checks anything out at all, rather than just doing a simple download for the files it needs).

I think it is worth consideration that GZDoom and Raze could be set to download specific versions from there - not whatever happens to be "master" at the time - similar to how submodules worked - that way if any breaking changes are ever introduced, the correct file versions would be used. "Updates" can be introduced project-side simply by bumping the version hash string.

[_mental_]

I don't think that specific version is needed here. Such submodules-like thing has the same flaws as the corresponding Git feature.
Compilation can be verified via continuous integration, while work-in-progress changes can be committed to own branches, and they will be built by CI as well.

[Graf Zahl]

In addition, since these libraries are external, there is generally no pressing need for constant updates because most of the time they provide no benefits. One should assume that official releases of such libraries are in a working state, especially if they are not brand new.

I wouldn't consider updating such a library for example, if it had just been updated days before a new GZDoom release.

We only need serious consideration if some library does a breaking API change, but such things would generally disqualify a library for me because it's no longer future proof.

[Rachael]

Well - I had always thought the key issue with submodules when we used it was not the branch versioning but the fact that they required so many extra steps to use.

[Graf Zahl]

That is true - but the versioning is also rather fragile.

[randi]

Cool. Would this also be a solution for compiling libvpx in a form we can use? I'd really like to get rid of that library version from EDuke32.

Looks like it:

Code: Select all

    Directory: D:\src\vcpkg\installed\x64-windows-mixed\lib

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d----           7/27/2022  8:54 PM                pkgconfig
-a---           7/27/2022  8:45 PM        2445252 FLAC.lib
-a---           7/27/2022  8:45 PM         898182 FLAC++.lib
-a---           7/27/2022  8:42 PM        1574812 libmp3lame-static.lib
-a---           7/27/2022  8:42 PM         279918 libmpghip-static.lib
-a---           7/27/2022  8:42 PM        1841400 mpg123.lib
-a---           7/27/2022  8:45 PM         114990 ogg.lib
-a---           7/27/2022  8:42 PM        3869682 opus.lib
-a---           7/27/2022  8:42 PM         415852 out123.lib
-a---           7/27/2022  8:54 PM           9412 sndfile.lib
-a---           7/27/2022  8:42 PM         645166 syn123.lib
-a---           7/27/2022  8:45 PM        1821784 vorbis.lib
-a---           7/27/2022  8:45 PM         890862 vorbisenc.lib
-a---           7/27/2022  8:45 PM         164190 vorbisfile.lib
-a---           7/29/2022  8:32 PM       11846880 vpx.lib
-a---           7/29/2022  8:32 PM         520192 vpx.pdb

    Directory: D:\src\vcpkg\installed\x64-windows-mixed\bin

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---           7/27/2022  8:54 PM        2536448 sndfile.dll
-a---           7/27/2022  8:54 PM        9711616 sndfile.pdb

You could also reverse the logic in the *64-windows-mixed.cmake file I gave in that post and make static libraries the default so that the dynamic libraries are the ones you need to explicitly specify:

Code: Select all

set(VCPKG_TARGET_ARCHITECTURE x64)

set(VCPKG_CRT_LINKAGE static)

if (${PORT} MATCHES "libsndfile")
    set(VCPKG_LIBRARY_LINKAGE dynamic)
else()
    set(VCPKG_LIBRARY_LINKAGE static)
endif()

[Graf Zahl]

Or maybe we do everything static and have one EXE for all again.

[_mental_]

Or maybe we do everything static and have one EXE for all again.

I wanted to propose this too.

[Graf Zahl]

The biggest problem here is, of course, what to do with ZMusic on Linux.
It has become very apparent that setting this up via CMake seems to be too much for many self-compilers.

We should also try to offload the entire library setup to a separate file, so that we do not have to maintain this separately for GZDoom and Raze, as both have the same dependencies, aside from ZMusic full vs. lite.

[_mental_]

I thought we are discussing Windows version only. macOS build is already 'everything static' except MoltenVK. Linux version will remain unchanged.

[Rachael]

Honestly I would prefer the Linux version to have everything built static too - then there wouldn't be a need for fancy appimages or flatpaks.

[Graf Zahl]

But you know that this will never *ever* work because as soon as we do such a thing they all come running, asking "How can we build with dynamic linking?" and we'd be back to square one.
We'd have to tell them in clearest terms that there is no support at all for self-built binaries.

And what about macOS? Build setup there is screwed up enough that I never managed to produce a distributable binary myself.

And even so, there's still indirect dependencies we have no control over.


So, how do we progress from here?

[Graf Zahl]

Here's what I built with vcpkg, this also covers two new libraries we're going to need: libwebp and libtheora. Webp looks like it is becoming a viable alternative to jpg, so if we go the external route it's an obvious thing to add.

Code: Select all

30.07.2022  10:06           284.770 bz2.lib
30.07.2022  10:05           850.916 FLAC++.lib
30.07.2022  10:05         2.349.690 FLAC.lib
30.07.2022  10:05         1.388.798 libmp3lame-static.lib
30.07.2022  10:05           263.936 libmpghip-static.lib
30.07.2022  10:05         1.682.132 mpg123.lib
30.07.2022  10:00           103.310 ogg.lib
30.07.2022  10:05         3.207.890 opus.lib
30.07.2022  10:05           400.596 out123.lib
30.07.2022  10:06         5.128.242 sndfile.lib
30.07.2022  10:05           580.706 syn123.lib
30.07.2022  10:00         1.134.728 theora.lib
30.07.2022  10:00           437.316 theoradec.lib
30.07.2022  10:00           938.110 theoraenc.lib
30.07.2022  10:16         3.749.290 turbojpeg.lib
30.07.2022  10:05         1.671.366 vorbis.lib
30.07.2022  10:05           877.932 vorbisenc.lib
30.07.2022  10:05           150.862 vorbisfile.lib
30.07.2022  10:04        10.162.878 vpx.lib
30.07.2022  10:04           520.192 vpx.pdb
30.07.2022  10:02         3.417.990 webp.lib
30.07.2022  10:02         1.519.190 webpdecoder.lib
30.07.2022  10:02           121.438 webpdemux.lib
30.07.2022  10:02           333.996 webpmux.lib
30.07.2022  10:02           429.326 zlib.lib

Of the remaining stuff in the "libraries" folder,
asmjit is customized and cannot be rebuilt from upstream
discordrpc is better left alone.
gdtoa is not available, also not a size issue.
glslang can only be offloaded if we do it for all platforms, because this is something where we cannot afford any different versions to be used at all. I think we better, leave this in the source tree to have full control.
fluidsynth will have to be built from Randi's modified project - I haven't set that up yet.