@Kisai thanks for summary, but discussing implementation details on Vogons is really inconvenient - it's too easy to derail the discussion or lose someone's comment. The most productive way forward will be to open two new topics in dosbox-staging bugtracker (one for MT32, other for Fluid), or maybe even PRs straight away (but both MT-32 patch and Fluidsynth support require so much additional work, that I think an issue will better than PR for now).
Before reading my essay below 😉 : both patches were included in ECE, so if you only want the ability to easily cherry-pick them - they're already there. If you want me to include modifications to these patches on a separate branches (not merged to master), then no problem - just point me to exact patches or to branch in your fork on GitHub. My comments below apply to merging MT-32 into the master branch of dosbox-staging.
Kisai wrote on 2020-02-08, 08:36:
Just to jump back in time here. I consider the MT32 and Fluidsynth patches to be important, but the way I build them is basically windows-specific. (...)
I also consider them important; MT32 more than Fluidsynth (based on brief time I looked at Fluidsynth patch, I think this approach is flawed). However, no Windows-specific solutions will land in dosbox-staging - whatever we'll include needs to run on Linux, Windows, and modern macOS. For most features it's rather easy, but MT32, Fluidsynth and Glide support will need to resolve lots of problems to get there.
Before a feature is merged to master (thus at some point will land in patch series resubmitted for upstream) we need to make sure it not only works and is technically on point, but also code is clean and largely follows the coding style, does not introduce any warnings nor obvious regressions, does not require building other projects manually or patching other projects just for dosbox, builds can be reproduced on CI, the feature is documented for users in README file, man page, or .conf documentation, there are no licensing issues, etc, etc.
Issues like this *will* be raised and considered during the review in PR.
Right now, the problem with MT32 patch is the Munt project itself - it is not packaged as a library by any Linux distribution, vcpkg, MSYS*, nor brew repos. This basically means we'll need to include relevant parts of Munt project with dosbox-staging source code (building it "on the side" is unacceptable) - it's nothing new, we already do it for decoders lib (formerly SDL_sound) and nuked OPL. There are several ways to do it (e.g. dump code, use git submodule, or extract subtree and merge project histories - the proper solution should be considered when it'll be time). Fortunately, Munt authors predicted this usecase and support it (hurray!). Unfortunately, DOSBox uses autoconf, which makes it infeasible - Munt's lib buildsystem and embedding is provided as cmake module only.
So, there are two options: either rewrite DOSBox buildsystem in cmake, or Munt's in autoconf. So far during development of dosbox-staging we wasted so much time working on stupid issues caused by autoconf, that we're completely sick of it - and we're not the only one: DOSBox-X is also tranistioning to cmake (or maybe they already finished, I'm not sure), dosbox retroarch cores also want to use cmake, cmake would make it easier to perform builds on Windows (we could get rid of separate Visual Studio buildsystem, as cmake works in VS), etc, etc.
So MT32 patch needs Munt, Munt needs cmake, using cmake means rewriting buildsystem... and now we arrive at the REAL problem here: if we rewrite the buildsystem, our future patches won't be accepted upstream for sure.
This is annoying because DOSBox maintainers stopped talking to us, do not review our patch series, and it seems like they are not interested in introducing SDL2 to DOSBox at all.
I still have hope that Qbix or other upstream maintainer will reconsider and start reviewing patches I've sent, but it is really small hope at this point.
However, silence from DOSBox maintainers is not a blocker from starting the work I described above - please create new issue on bugtracker so we can start planning to make this work go smoothly. Personally, there are is so much interest in dosbox-staging at the moment, that I have my hands full already - which is a good thing, I guess 😀 All new contributors are welcome.