Transition to ZMusic as DLL

[Blzut3]

Then - all projects using ZMusic can simply use the same ZMusic on the same commit.

Keep in mind that ECWolf is a potential ZMusic customer. I have no intention of joining a mono-repo. I'm already using submodules for SDL anyway.

Git submodules are a bit quirky in that they aren't cloned by default, and aren't updated automatically by default when you pull. This was something Mercurial got right. In any case though with ECWolf my submodules are entirely optional. If they're cloned then you can mono-build a static ECWolf binary. Or you can provide system libraries if you prefer regardless of if the submodule is present or not. The same should be done for ZMusic in my opinion, but like I said the legacy design of the GZDoom CMakeLists is going to make that a little painful so that needs to be cleaned up first.

Git supports subrepositories. I think that's probably the best way.

I thought about that too, but anyone's who's ever used them only seems to talk of pain and torment.

Despite the horror stories they do the job just fine. They just could have been implemented in a more user friendly manner. (Some of this can probably be fixed by setting submodule.recurse to true in Git but I'm not sure why it isn't the default and don't have experience with that setting. My gut says trust the default and just run "--recurse-submodules" or "git submodule update" manually as needed.) Ultimately the thing to consider here is that Git treats submodules as if it was a completely unrelated repo. So in the worst case it's exactly the same amount of work as if it wasn't part of the GZDoom/Raze tree. In the best case scenario it "just works."

To me the pain only comes when it comes to CI. Bitbucket Pipelines just doesn't support submodules natively (no idea on Github's CI service), so you have to do work arounds. But you have to do more work anyway if ZMusic is not a submodule. So it's one of those "it may not be exactly what we want, but it's not worse" kind of things.

The idea here is to have a STABLE API

Stable API and ABI I hope. Otherwise packaging separately on Linux is a no-go. Well not technically, but it would make attempts to do so kind of pointless.

i.e. if new music formats get added they should become automatically usable without recompilation.

I fully expect to have to write this feature myself, but fyi when it comes to ECWolf I want to be able to opt into format/codec support. Right now ECWolf intentionally uses a version of SDL_mixer that only supports Xiph codecs, modplug, midi (sort of), and of course WAV PCM. Don't intend to support mods with random formats when one of the supported will do just fine.

[Graf Zahl]

I'm sure that all you'd like to see can be done, but let me repeat that my knowledge of CMake is not good enough to clean up the scripts and I simply do not have the time to learn how this can be done. Unforrtunately, when it comes to documentation and tutorials, CMake falls a bit short. But if the library can be made more user friendly, all the better - I'm all for it.