I built standalone mt32emu.dll for MSYS2/Mingw-w64 and my DOSBox SVN uses it. I did not use cmake. I write my own GNU Makefile just for building the DLL and its supporting lib.a and lib.dll.a for static/dynamic linking.

I know getting it build is not a problem, getting it into the package manager is 😉

I don't know if you want to do it this way: you can add a patch to add the Makefile and use it to build just the DLL. I was thinking of doing that for pacman package reuse, but never actually did it.

I actually may have to do something like that, because I didn't realize that both mt32emu and the programs build want to install the header files in include.
That creates a conflict in the package manager, as it should in a good package manager...
*sigh*

My 5 cents (if I'm not too late 😉 ).

As for the technical part of the question. The provided CMake files foresee building either of:
- a package that consists of the two mentioned apps with the library statically linked (by default, but it is _very easy_ to tweak with the cmake options);
- a library alone (either static or shared, with or without headers - see the available build options);
- any of the apps alone.

If you only want to build 1 particular thing, you can merely run cmake from the related subdirectory. Alternatively, you may disable building of any or both programs with options munt_WITH_MT32EMU_SMF2WAV / munt_WITH_MT32EMU_QT.

As for licensing part - I am certainly not a qualified lawyer but I get it as the library can be freely used / distributed under LGPL 2.1 or GPL2 or any later version (as the README.md says). There is no special restrictions applied to enforce packaging. Any of the munt components are fairly stand-alone products put into a single git repo due to a preference of (some) devs. Note, I do provide separate packages for *NIX systems, and Linux packages are even separate devel/bin ones (for the sake of fitness to the Debian/Red Hat policies). And I see 0 potential issues wrt. packaging like that or together with apps (like we do for Windows systems).

@Dominus, please let me know if something unclear remains now 😀

Technical question remains:
If you just let cmake configure from the munt root, the static mt32emu is only needed to build the programs. And after these are built the static lib and headers are not needed anymore (since statically built in), right?
I'm asking as both the static lib and headers are left as install targets. Can this be prevented through some cmakery?

Unfortunately, the cmake build script for the entire package doesn't seem to permit doing it easily (we didn't define fair cmake components there). And for some reason, the library is considered a mandatory thing, so is built and packaged no matter what 😀

But as I said, there is a simple workaround: just doing

1make package

from e.g. mt32emu_qt directory will create a stand-alone package with just that component (no includes/.a/.dll files whatsoever).

Thanks. After asking I decided to go the way you described and will then hopefully have a good package script for the MSYS2 maintainers.
First one that builds everything (as they prefer) and another way that splits it up in munt programs and lib.

I'll add the third option wrt. packaging the library withing the top-level package ASAP.

https://github.com/msys2/MINGW-packages/pull/7812 <- my pull request for the MSYS2 packaging. One all-in-one solution and another one to have a standalone library without the QT5, glib2 and portaudio overhead.
I *hope* they accept this and I *hope* they go for the split solution 😀

Thanks for your help!

FYI, with some improvements as of this commit, it should become easier than ever 😜

oh, yes, that looks nice. I'll make sure to upgrade the package once a new version of Munt lands.
Damn... here I am, having to create packages for a Windows thing, while I don't really use Windows since 12 years 😀

Well, I stop caring about that point having deployed 6th virtual machine on by "build farm" 🤣

😀 our trusted Windows snapshot creator disappeared last year and now I have to do our snapshots in a VM as well. Only because Msys2 won't run in Wine 😀

That's weird. I supposed the MinGW toolchain works just fine if installed from brew. Is there some problem with that approach?

I think I tried once with mingw done by MacPorts but ran into some problems and gave up. It's one of my goals to eventually have a working toolchain in macOS to crosscompile but there is always so much stuff to fix left and right 😀
That Msys2 has problems with WINE is well documented but no fix for now 🙁

If you are interested my branch of Exult that replaces the builtin munt with the lib is at https://github.com/DominusExult/exult/tree/libmt32emu with a minimal mt32emu lib xcode project file for ios at https://github.com/DominusExult/exult/blob/li … project.pbxproj (it just assumes the lib sources are dropped in the mt32emu subfolder same as the sourced for SDL2, ogg/vorbis respectively)

Managed to get it accepted into MacPorts as well https://github.com/macports/macports-ports/pull/9842 (with a lot of back and forth because I was sloppy with spacing, newline etc...).

I've also just submitted a pull request on Munt to generate a pkg-config file. I found that to be useful 😀

What I cannot do and would be mildly useful is to have one target that builds both the dynamic and static library but what I gathered from searches this doesn't seem to be an easy cmake task.

Dominus wrote on 2021-01-30, 16:07:

Managed to get it accepted into MacPorts as well https://github.com/macports/macports-ports/pull/9842 (with a lot of back and forth because I was sloppy with spacing, newline etc...).

Cool, thank you! 😀

What I cannot do and would be mildly useful is to have one target that builds both the dynamic and static library but what I gathered from searches this doesn't seem to be an easy cmake task.

Apparently, this is actually doable, even without components. For example, portaudio merely builds both variants at once having two targets in their CMakeLists.txt. I'm just not sure if this is very useful since one would need either a static or dynamic lib and the majority of distributions prohibit static linking altogether.

sergm wrote on 2021-01-30, 18:36:

Dominus wrote on 2021-01-30, 16:07:

Managed to get it accepted into MacPorts as well https://github.com/macports/macports-ports/pull/9842 (with a lot of back and forth because I was sloppy with spacing, newline etc...).

Cool, thank you! 😀

No problem, it's not like there wasn't a selfish agenda 😀 (for easy instructions in Exult 😀)

What I cannot do and would be mildly useful is to have one target that builds both the dynamic and static library but what I gathered from searches this doesn't seem to be an easy cmake task.

Apparently, this is actually doable, even without components. For example, portaudio merely builds both variants at once having two targets in their CMakeLists.txt. I'm just not sure if this is very useful since one would need either a static or dynamic lib and the majority of distributions prohibit static linking altogether.

yes, hence the "mildly useful". For my personal use I have my own prefix anyway that has both shared and static library, so it might be that I was staring at things too much anyway 😀