Remove support for MSYS2

[tresf]

MSYS2 support was added 9 years ago as an effort to help with crashes surrounding #1991 as -- at that time -- there was no official support for the MSVC compiler.

MSYS2 had several issues:

• There were no precompiled binaries, a script was needed to fetch them from Ubuntu PPAs
• The Qt instance provided by msys2 was missing features, a script was needed to merge the runtime from the Ubuntu PPA
• The mix of POSIX and Windows tools caused issues with path calculations
• Several plugins are broken or missing when building with MSYS2
• The end-goal of obtaining a debug build of LMMS was never fruitful

In the years since MSYS2 was added, MSVC support has greatly improved and is now considered the preferred way to build on Windows.

As a cleanup effort, I believe MSYS2 can safely be removed. If at a later time the project chooses to re-add support for MSYS2, it would be welcome, but ideally would look much different than the broken system that is in the codebase today.

[Kreijstal]

it seems that is msys, not msys2?

[tresf]

it seems that is msys, not msys2?

Can you please offer some context to this statement?

• To disabiguize this for onlookers of what msys2 is (e.g. versus msys) https://stackoverflow.com/a/25023611/3196753

It's MSYS2:

• The oldest compile reference we have for this (that's still accessible via the web) is a wiki article that I published in 2017: https://github.com/LMMS/lmms/wiki/Dependencies-Windows/df0b9e4faeb1886809535910f409a1b0729a4367, which clearly uses MSYS2. (The article is likely much older than this, but would be hidden in the wiki's commit log, which I'm not great at traversing).
• The commit which largely introduced MSYS2 to our codebase is here: tresf@a7f8251. Notice that the code is largely influenced by the MSYSCON environment variable.

Although the disambiguous article linked above clearly states:

[...] We would ask that you never mix MSYS2 with msys or msysgit [...]

... this was unknown by me at the time of writing original support (it was unknown by me until just now) so our variables and notes in the code certainly may add ambiguity to this to a casual onlooker, however I would argue that this confusion is self-inflicted and widespread.

Here's an example of MSYS2 questions being improperly tagged on stackoverflow:

• https://superuser.com/questions/tagged/msys

Moving forward, I'll try to be more accurate as to disambiguate these two terms, however much like JACK1 vs JACK2, people will continue to call the technology whatever they want and leave it to technical people to read between the lines.

That said, we'll be re-adding MSYS2 support back into our build system soon. This effort is being tracked partly (and unobviously) in #7526.... Conversation starts around here: #7526 (comment). Our wiki will be updated once the steps are viable.

[Kreijstal]

That said, we'll be re-adding MSYS2 support back into our build system soon. This effort is being tracked partly (and unobviously) in #7526.... Conversation starts around here: #7526 (comment).

Oh that's great, I just made a package request so that libgig gets packaged on msys2
msys2/MINGW-packages#22740

[tresf]

That said, we'll be re-adding MSYS2 support back into our build system soon. This effort is being tracked partly (and unobviously) in #7526.... Conversation starts around here: #7526 (comment).

Oh that's great, I just made a package request so that libgig gets packaged on msys2 msys2/MINGW-packages#22740

Thank you for sharing!

Pinging @FyiurAmron, since they're spearheading this effort, it may be a thread worth following. 🍻

[FyiurAmron]

That said, we'll be re-adding MSYS2 support back into our build system soon.

TBH, I'd say the support is there, more or less, only the docs are probably lacking (haven't checked them in a while, job+RL tasks full my schedule 150% lately :)

@Kreijstal I was able to do a MSYS2 build basically out-of-the-box after the chain of updates I merged during the summer - see #7358 for more info there. While the task mentions Ubuntu 24, it actually handled stuff required for recent MSYS2 setups as well, due to the rolling-update specifics of MSYS2 package system (i.e. using old deps and tools for compatibility with legacy code is relatively hard in MSYS2). There might be some things that changed in the meantime, but I'd still say that you can try adding the deps and running build and get a surprisingly high success ratio :)

Many thanks for the update BTW! 🍻

[Kreijstal]

Many thanks for the update BTW

@FyiurAmron yeah, one thing to be careful is this only builds with msys2 (cygwin) perl and not mingw's perl, other than that it seems I managed to build it as well. If you have mingw's perl, you might need to uninstall it.

[bratpeki]

This effort is being tracked partly (and unobviously) in #7526

Very unobviously, indeed! The issue was started as an attempt to get WSL to build a native Windows LMMS build, but the conversation shifted over to "native solution for a native platform". I'll change the name of the issue so it's more appropriate!

[Kreijstal]

This effort is being tracked partly (and unobviously) in #7526

Very unobviously, indeed! The issue was started as an attempt to get WSL to build a native Windows LMMS build, but the conversation shifted over to "native solution for a native platform". I'll change the name of the issue so it's more appropriate!

You can use msys2 in linux tho
https://github.com/msys2/msys2-docker.git
however youd need to wait for a new image since libgig is pretty new addition

[bratpeki]

You can use msys2 in linux tho

That's cool, but building on Linux is ridicolously easy in comparison to the methods currently presented on Windows, which are either getting a separate Ubuntu 20 boot or using some practically graphical solutions (IIRC).

MSYS2 is showing itself to be a great way to build on Windows, so to not suffer feature creep, I'd rather we just make the command list we can present those on the Wiki for people eager to compile for Windows, on Windows.

[tresf]

This effort is being tracked partly (and unobviously) in #7526

Very unobviously, indeed! The issue was started as an attempt to get WSL to build a native Windows LMMS build, but the conversation shifted over to "native solution for a native platform". I'll change the name of the issue so it's more appropriate!

You can use msys2 in linux tho https://github.com/msys2/msys2-docker.git however youd need to wait for a new image since libgig is pretty new addition

@Kreijstal this probably isn't the right place to start such a conversation, but can you please help explain what the "msys2 in linux" is? Is this a Wine-driven msys2 environment? If so, this may help solve some outdated dependency issues that we battle with our PPAs.

That said, I'm not a fan of asking our developers to use a container for building as it obfuscates troubleshooting, but I'm curious as to the options/viability. Feel free to open a brand new discussion if you wish and tag the relevant parties.
https://github.com/LMMS/lmms/discussions

[Kreijstal]

This effort is being tracked partly (and unobviously) in #7526

Very unobviously, indeed! The issue was started as an attempt to get WSL to build a native Windows LMMS build, but the conversation shifted over to "native solution for a native platform". I'll change the name of the issue so it's more appropriate!

You can use msys2 in linux tho https://github.com/msys2/msys2-docker.git however youd need to wait for a new image since libgig is pretty new addition

@Kreijstal this probably isn't the right place to start such a conversation, but can you please help explain what the "msys2 in linux" is? Is this a Wine-driven msys2 environment? If so, this may help solve some outdated dependency issues that we battle with our PPAs.

That said, I'm not a fan of asking our developers to use a container for building as it obfuscates troubleshooting, but I'm curious as to the options/viability. Feel free to open a brand new discussion if you wish and tag the relevant parties. https://github.com/LMMS/lmms/discussions

y-yeah, it's wine