VOGONS


First post, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Heya,
I'm trying to get Munt into MSYS2/Wingw packaging and since no one there reacted on my packaging request I'm doing the work myself 😉
But I've run into a little problem with the MSYS2 maintainers: I would like to split Munt into two packages, the QT-GUI+Smf2wav (as Munt) and mt32emu for the library (because of it not depending on anything, so quick to install).
But they'd rather have it in one package so I may have to get that ready before starting my request to split it.

So my question is, can you even build the standalone libmt32emu while building the munt programs? From the lib's cmake file it seems the answer is no.

License:
mt32emu is both LGPL 2.1 and GPL 2? (Because the GPL 2 copying.txt is still in its folder)
The two programs are GPL3 (but since you can only package it with mt32emu you need to include that license). Correct?

The reason I push for the package (more text):
I want to switch Exult from an hoplessly out of date integrated mt32emu to the library but the last step is having the lib in an easy, automated way (I could provide binaries but then it would still clash with automated build testing).

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 1 of 19, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

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.

Last edited by kjliew on 2021-01-26, 08:37. Edited 1 time in total.

Reply 2 of 19, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

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

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 4 of 19, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

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*

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 5 of 19, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

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 😀

Reply 6 of 19, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

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?

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 7 of 19, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

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

make package

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

Reply 8 of 19, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

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.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 10 of 19, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

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!

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 12 of 19, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

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 😀

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 14 of 19, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

😀 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 😀

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 16 of 19, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

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)

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 17 of 19, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

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.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 18 of 19, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 19 of 19, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator
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 😀

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox