Defining an MSYS2 build command list #7526
Comments
|
This could have something to do with versioning (Bullseye, Buster, etc), but I don't know. |
bratpeki
changed the title
|
Solved it with |
|
Fixed with |
|
Then running WSL uses Bookworm: |
|
Tobydox's PPA is for Ubuntu 20.04 (focal), not Debian 12 (bookworm): https://ppa.launchpadcontent.net/tobydox/mingw-w64/ubuntu/dists/focal/ It looks like @FyiurAmron erroneously changed the wiki article to say "Debian" rather than "Ubuntu" starting with this revision: https://github.com/LMMS/lmms/wiki/Dependencies-Windows/4b141b4f8fb77c9cd46799e2e87f6a9499dcd03a I just changed it back to "Ubuntu". While you probably could get it to work on Debian, we do not officially support anything other than what our automated builds use, which is Ubuntu 20.04. |
|
@messmerd FWIW, you're completely right here, I tried to recall why I changed that but couldn't find any rational reason, probably were just editing 3 pages at once and went on a spree and done this due to some brain fart. Maybe I wanted to describe the exact procedure for normal Debian distros in-depth and either forgotten about that or gave up on it, or maybe it was just a completely random mistake. Can't recall now, the last months been hectic for me. Anyhow, I 100% agree, although technically Ubuntu still is Debian, just repackaged :D (and yes, with the deps either built from source or otherwise repackaged, I see no reason why it wouldn't work, but I also see no reliable way to support people doing that since I'm not using raw Debian on a daily basis anymore and I guess it's an edge case anyhow) @bratpeki tl;dr those PPAs are a relic from the past, so compiling them libs from source would be your best bet - but while you could do that or even try to configure APT to fetch those for |
|
Excellent, thank you both! I'll move the compilation process to MSYS, then! @FyiurAmron, where can I find relevant documentation, if any? I'm persuming MSYS2 is focused on using Pacman, so I could get the dependency list off the lmms-git AUR repo, but is there anything on the LMMS Wiki regarding this? (Update: MSYS' Pacman is definitely not housing the same packages as Arch's Pacman, for anyone learning about it and reading this in the future, LOL) |
|
@bratpeki doh! Now I recall, I was in the process of updating those docs when RL stuff struck me. Found some commented out doc blocks hinting on what I wanted to do next, and it was indeed providing docs for MSYS process, and perhaps Debian afterwards. It's quite straightforward for MSYS anyway and strictly follows what's described on https://github.com/LMMS/lmms/wiki/Compiling for other compile paths; I'll post you the exact file I guess was supposed to be the basis of the doc: After getting the libs installed, prepare the dirs for make ( If it works for you, feel free to add this or any other relevant data to the wiki as new section. We had some outdated docs for MSYS in the olden days, but https://github.com/LMMS/lmms/wiki/Dependencies-Windows/_compare/a857e2562de0d13a5387d75db2508c9cf7127641...6cfbc94f040dce913ab456429c1b2b897dad1167 removed them a couple of months ago (not that it was a wrong call by itself, that part was outdated as hell and was also mostly unnecessary anymore). |
|
Wonderful, thank you! I'd help you keep the building Wiki page up-to-date, if necessary, and I believe the cmake commands should be different, to specify the output binary is a Windows one! |
I believe I should either choose 1 or 3, looking into it now. |
@bratpeki From what I recall, MSYS's cmake can only output Win32/64 binary, so no need to instruct it to do so. The commands should work as-is (maybe you'll need to tell CMake to use Unix buildfiles instead of Ninjas etc., but YMMV there, I just didn't have any luck with Ninja builds, some random errors started happening). |
You'll need all 13 of them IIRC. Some are optional-ish (gdb e.g.), but most of them are strictly required, and there is no harm in having them all anyway. |
|
After finnicking around with my antivirus software, I am pleased to announced I've compiled it! The instructions were straight-to-the point, with the exception of having to restart! |
|
When attempting to run from the |
TBH, I never had to do that for MSYS, but obviously YMMV here, I'm still on old-ish MSYS version on Win7, maybe Win10 version changed something, maybe you were just unlucky with your particular setup for some reason.
It should be possible on both. However, to do that on Windows you'd have to have a dir with those DLLs in a shared location (i.e. on Windows PATH) for this to work without having the DLLs bundled in the same dir. That's one way to handle it, althout some files required for "normal" LMMS work might be missing anyway (I'm not using this one personally for that reason). Another way is to use CMake to create an NSIS build to get a complete package with all the DLLs bundled. AFAIK you'll get all the needed files in Yet another approach is to just copy the exe from build to an existing 1.3.0-alpha install location and either overwrite the old one or rename one of them. This one should be fool-proof as well, drag-n-drop or one-liner is needed only. Renaming the exes allows you to compare the different build versions side-by-side as well too, so it's a 10/10 approach in my book. You might also mix the above solutions in any way you fancy, obviously. Do what suits you best. |
|
Or you can just |
|
@Rossmaxx a very good point. So, in total, that's at least 4 reliable methods to handle this. Should be enough :D |
|
Thank you both! This works like a charm with an out of the box MSYS2 install. I think I could write up an addition to the PR, as this seems like a very easy way to get building up and running on Windows! I'll give Ross' command and packaging a shot, and let you know how it goes. |
Works like a charm! |
|
I have utilized the following build rules, and I'm just sending them to have them saved and formatted, as well as present my progress:
mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX=../target
cmake --build . --target packageThis makes using Ninja by default and installs the files to
mkdir build
cd build
cmake -G "MSYS Makefiles" ..
make
cmake --install . --prefix "../target/" |
|
So can we close? |
|
Just let me make a proposed edit to the Wiki and we can close! |
Morbid curiosity, but why not use an Ubuntu WSL instance? |
|
I am also intending to try an Ubuntu WSL, since I made an issue of trying to compile on Debian, which isn't officially supported. I realized my mistake only recently, and forgot to write about it. Thank you for commenting, that reminded me to write! Also relevant:
|
|
Also, @FyiurAmron generally recommended MSYS, saying that the PPAs are "a relic of the past", so I'm intending to provide both compilation methods, if compiling with the PPAs is still possible. If I have trouble we can't overcome, MSYS has proved to be ridiculously simple! |
This may be a bit outdated (6 years old) but here's how I did it last: https://gist.github.com/tresf/3c739a739b56d8dc0679c3f2f85c349d |
For cross-compiling, I'm unaware of an equivalent to Toby's PPA. I think cross-compiling is a nice option however we may decide to remove if if keeping the PPAs around is too much work. |
|
So we would have to provide the |
the thing I just wrote is the PKGBUILD file you have to edit it to fix the issues, try makepkg-mingw command on the same directory where this file is |
|
Will do! I'm just wondering if that means we need to append the above file along with the Windows build instructions, for example, in the Wiki; or if we can add it to the MSYS2 package database via a PR or something, since w custom made PKG build defo means it's missing from MSYS2. Then again, this could be a super specific library, so we could just add it to the build instruction and call it a day. |
You can add a PR to msys2 once you verify it works |
|
Alright, so, we've had one user test the build instructions and their experience matches my own, so I think we're good to go (EDIT: They've successfully built it). @Rossmaxx is down with releasing experimental build instructions, without LIBSTK support, and then moving this to a new issue, where we can focus on that, since this issue is huge and changed direction halfway through. Standard buildingInstalls LMMS to pacman -Syu --noconfirm
pacman -S perl-List-MoreUtils perl-XML-Parser pactoys base-devel git --needed --noconfirm
pacboy -S jack2:p cmake:p cc:p libsndfile:p fluidsynth:p fltk:p fftw:p libsamplerate:p libgig:p SDL2:p qt5-base:p lv2:p lilv:p suil:p --needed --noconfirm
git clone https://github.com/LMMS/lmms.git
cd lmms
cmake -B build
cmake --build build # -jNUMOFTHREADS
cmake --install build --prefix "target"NSIS buildingIdentical, with the excpetion of generating an NSIS installer in the build directory. pacman -Syu --noconfirm
pacman -S perl-List-MoreUtils perl-XML-Parser pactoys base-devel git --needed --noconfirm
pacboy -S jack2:p cmake:p cc:p libsndfile:p fluidsynth:p fltk:p fftw:p libsamplerate:p libgig:p SDL2:p qt5-base:p lv2:p lilv:p suil:p --needed --noconfirm
git clone https://github.com/LMMS/lmms.git
cd lmms
cmake -B build -DCMAKE_INSTALL_PREFIX=../target
cmake --build build --target package # -jNUMOFTHREADS
cmake --install build --prefix "target" |
|
@messmerd Are you fine with the proposition made above? If so, I'd contribute these two rules. |
|
@bratpeki It looks like you're not using |
|
From my experience, CMake checks and resolves that. However, I will change that ASAP to remove ambiguity. |
It will make builds very very slow, and download things that are already provided by msys2. Recursive isn't necessary. if a component is needed, cmake will clone it all by itself. |
|
That definitely needs some verification. What would it download again? Why would the builds be that much slower? |
because you would download ALL vendored submodules of course, instead of using the already provided msys2 ones. For example, try building with git clone --recursive and git clone without recursive and see the recursive build takes more time downloading. |
|
Oh, fair, that's a first-time build, so I wouldn't count on it being a significant factor. As long as the build in the general case isn't slower, we're good. However, if it's true that CMake doesn't get all submodules, but only the necessary ones, then we shouldn't use the recursive clone, since we are making the first build slower. |
|
that depends on your cmake configuration of course, you could configure cmake to get ALL modules regardless of if you need them or not... but that's... wasteful. |
|
@messmerd I'm testing another PR right now, and check this out:
CMake checks the submodules. |
in this case it'd be wasteful since x11 doesn't exist (not very well anyway) on windows |
|
We could well open a separate issue, @Kreijstal. |
This can safely be omitted if you wish, but the source code for this particular project is 36K zipped / 84K with history. It's not a low hanging fruit in regards to clone speed.
I'm curious which vendor submodules fall into this category? Naturally if they're being cloned redundantly, we can handle this better in cmake. The reason we have cmake clone them is exactly for the bandwidth reasons being mentioned (specifically, the |
|
Added the text! I'll verify the build commands one more time, just to make sure I'm not lying about the directories where everything can be found, and such! |
|
Verified! As far as I'm concerned, if the Wiki text is to your liking, we can close this! |
|
Thanks for this work. cmake -B build -DCMAKE_INSTALL_PREFIX=../target
cmake --build build --target package # -jNUMOFTHREADS
cmake --install build --prefix "target"Hmm... I would expect
I'll be testing this today and I'll report my findings. I've also updated the wiki with some basic formatting changes here: https://github.com/LMMS/lmms/wiki/Dependencies-Windows/_compare/4e0b9fcb2a134d5a53990f81c1ae41f4005cbaa8...34dd1449d8da3c26c7baa93bf511085c769fc3fd. To the point of packaging, we generally document the packaging steps elsewhere, so it may make sense to shorten the tutorial to just the compiling steps and then link to the packaging steps. https://github.com/LMMS/lmms/wiki/Compiling#windows-packaging. At time of writing this, the packaging steps appeare to be broken for MSVC and MSYS2, so we should be able to update those to be correct for all build systems. |
Hmm. FWIW, I was able to get a proper NSIS installer built on MSYS2 some time ago I think? 🤔 |
Likely because you already had nsis installed, but the package is missing from our wiki (and CLANGARM64 doesn't provide one). |
I had a small discussion on Discord and @bratpeki said they'd look into this, but I'm able to confirm that there's no real advantage of using |
Afaik install is used for distro scripts aka archlinux debian to make deb packaged for example |
Yes, however our instructions historically used it as a temporary install location for testing (putting plugins, etc in their right places). However, since then we've greatly improved the ability to run the software without installing. I've tested locally and can confirm that it's not needed. This has been removed from the wiki.
This puts us in great shape on MSYS2. Thank you to all that contributed to this effort. I'm really blown away by how mature of a build system msys2 is. This issue appears to be resolved but please feel free to comment on it if needed. |
System Information
Windows 10
LMMS Version(s)
Git
Most Recent Working Version
No response
Bug Summary
Following https://github.com/LMMS/lmms/wiki/dependencies-windows#linux-cross-compile to compile on Windows is not straightforward.
I set up Debian using WSL2 on my machine.
The
sudo add-apt-repository ppa:tobydox/mingw-w64command gives the following result:Expected Behaviour
The command gives no errors, and one may proceed with the compilation steps.
Steps To Reproduce
sudo apt updateandsudo apt install software-properties-commonLogs
Screenshots / Minimum Reproducible Project
No response
Please search the issue tracker for existing bug reports before submitting your own.
The text was updated successfully, but these errors were encountered: