Welcome to the ZDoom Forums!

Regarding macOS, I continue to support this repo. It has everything to build a bundle with no external dependencies for both architectures. Prerequisites are the recent version of macOS (10.15+), and Xcode that handles x64/arm64 (12+).

How about moving that to the ZDoom organization as well, so that it is easier found by those who want to self-compile?

Done.

Could you add a bit more info to the usage section? It's a bit unclear what the parameters for --target and --source should contain.
It may also make sense to rewrite https://zdoom.org/wiki/Compile_ZDoom_on_Mac_OS_X to use this project. That page is totally outdated and IMO perfectly useless. It also seems to be a lot easier using your setup, so documenting it may be a good idea.

The mandatory switch is either --target or --source.
Run build.py without arguments. It will output the list of possible values to use with --target.
For --source, the value is a path to source code.

Pretty much the same is written at Usage section. I have no idea how to explain it better.

'path to source' means path to main CMakeLists.txt?

No, it's a path to directory with source code, i.e. the root of Git repository with source code.
This argument is named --source because --source-path has a different meaning. It's a directory where source codes of all targets are stored.

Ok, I'll try that the next time I am on my work Mac.

I'm still stuck building FluidSynth as a static library. What do I have to change there to build that instead of a DLL?

Graf Zahl wrote:

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.

While the Raze package I maintain in Arch Linux's AUR maintains the repository-included libraries, some distros are going to the effort to unbundle these so system libraries are used.

Could we have it so distro-provided builds of GZDoom and Raze are supported, just so long as they're built to our specification, with our tested and mandated libraries? I don't know of any distros that will repackage someone else's binaries, especially when there is source availalble.

Graf Zahl wrote:I'm still stuck building FluidSynth as a static library. What do I have to change there to build that instead of a DLL?

Configure it with BUILD_SHARED_LIBS turned off.

mjr4077au wrote:

Graf Zahl wrote:

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.

While the Raze package I maintain in Arch Linux's AUR maintains the repository-included libraries, some distros are going to the effort to unbundle these so system libraries are used.

Could we have it so distro-provided builds of GZDoom and Raze are supported, just so long as they're built to our specification, with our tested and mandated libraries? I don't know of any distros that will repackage someone else's binaries, especially when there is source availalble.

If we link those libraries statically, there's nothing to unbundle as it's all in one file.
These Linux people are a lost cause, they really screw everything up they put their dirty fingers in.

FluidSynth compiles now, but there's one problem left. Whatever I set for SNDFILE_DIR, when I hit "generate" the entry gets cleared again and sndfile support is disabled. The CMake script is doing a lot of verification voodoo to see if the library is usable and this fails somehow.

Set SNDFILE_INCLUDE_DIR and SNDFILE_LIBRARY variables to directory with headers and .lib file correspondingly.

I only have SNDFILE_DIR, these two are not listed.

It appeared that FluidSynth uses pkg-config to find sndfile. I never tried to workaround it on Windows, and I don't have Windows PC at hand to play with it.