Building LMMS on Windows should be easier

[ghost]

I have attempted to build LMMS from source, following the suggested tutorial in the wiki: https://github.com/LMMS/lmms/wiki/Compiling-lmms-(On-Windows).

Unfortunately, the main build script supplied, msys_helper.sh (retrieved from https://raw.githubusercontent.com/lmms/lmms/master/cmake/msys/msys_helper.sh), fails to fetch and build all of the dependencies, and I had to edit /lmms/blob/master/cmake/msys/fetch_ppa.sh to fetch the correct packages:

@@ -41,15 +41,13 @@ mkdir $ppa_dir

 while read -r j
 do
-       if [ "$j" = "Filename:" ] ; then
-               continue
-       fi
        echo "Downloading $j..."
-       wget -O "$ppa_dir$(basename "$j")" "$PPA_ROOT/$j"
+       echo "$PPA_ROOT/$j"
+       wget -O "$ppa_dir$(basename "$j")" "$(echo "$PPA_ROOT/$j" | sed 's/\/Filename: /\//gi')"
 done < $temp_file

After running msys_helper.sh again, other libraries such as FLTK compile successfully, except for libgig since it cannot find the appropriate package config entries for libsndfile, even though it's package did install sucessfully. This could be manually fixed by adding a .pc file in \msys64\usr\lib\pkgconfig, although it would be good if the .pc file was installed from the original package.

I wish that the static libraries were in a folder called 'lib', and the include files in 'include', and that the configuration tasks be within cmake scripts.

[tresf]

We welcome PRs to make this process better.

I don't think we ever got libgig working. Edit: Seems to have been broken since #3369. If we can fetch the upstream .pc file, that would be ideal since like you mentioned the other environments have this already, it would be redundant to bundle in our own .pc

The long term goal for Windows development is to offer full MSVC++ support on a non-POSIX environment. This means moving from msys2 to something like cmd, or ideally PowerShell.

I'm working with scoop.sh on consolidating our package manager into something more Windows friendly and more sustainable (wget ELF binaries is just the wrong way, but the DLLs are usable, so it's an OK hack for now).

I can't do this alone so if you have time to hit me/us up on Discord, #devtalk (by request only) and #opendev (open to public) are good channels to hash this out.

We used to only build packages from source which suffered from name mangling and segfaults but some recent work from @dragoneagle have changed this in #3369. Restoring the old functionality would likely get gig back and working on Windows I think

https://discord.gg/5kSc32Z

[Umcaruje]

@edition-ben what's your windows version? I did a fresh clean compile on Windows 10 and it worked perfectly. The only problem I had was the script couldn't acquire the libgig tar cause the linuxsampler website had issues. I solved it by replacing the link with one from the web archive.
Comment here: #3369 (comment)

[eagles051387]

Has anyone tried to use the Linux subsystem on windows to build? It might help make things easier. I have tried it and it's based on ubuntu. Not sure what version though

…

Sent from my iPhone

On 08 Apr 2017, at 18:40, Umcaruje ***@***.***> wrote: @edition-ben what's your windows version? I did a fresh clean install from my windows 10 and it worked perfectly. The only problem I had was the script couldn't acquire the libgig tar cause the linuxsampler website had issues. I solved it by replacing the link with one from the web archive. Comment here: #3369 (comment) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[tresf]

No, not yet. Bash on Windows 10 is ELF based, so it would still require Toby's PPAs and the Linux cross compiler.

[tresf]

other libraries [...] compile successfully, except for libgig since it cannot find the appropriate package config entries for libsndfile, even though it's package did install sucessfully.

I did a fresh clean compile on Windows 10 and it worked perfectly.

Me too. Just did a fresh build on Server 2016 Core and it worked. Interestingly enough, so did @UnityParadox after committing f9e01b5 and his libgig compiles but his LMMS won't.

I had to edit /lmms/blob/master/cmake/msys/fetch_ppa.sh to fetch the correct packages:

Me too, fixed via f9e01b5, thanks for the code.

At this point I'm wondering if something is accidentally wiping out or caching and old value of PKG_CONFIG_PATH and/or PKG_CONFIG as the cmake step has been fixed with the recent patch.

[tresf]

To elaborate a bit more on the PKG_CONFIG suspicion...

This could be manually fixed by adding a .pc file in \msys64\usr\lib\pkgconfig

• @UnityParadox and I investigated this and found the file is located in /mingw64/lib/pkgconfig.
• When we check this against echo $PKG_CONFIG_PATH, we get /mingw64/lib/pkgconfig:/mingw64/share/pkgconfig, which looks reasonable.
• Finally, we run pkg-config.exe --modversion sndfile and get 1.0.26pre5, so it appears to be working.

[tresf]

Ok, we worked through it... It appears something is different between environments, specifically $PKG_CONFIG_PATH. Fixed via 4e76b78 on master branch.

Please confirm and then we can close this issue out.

In regards to the other requests (lib/ and include/ points), they really are going to rely on the long-term build system we use and should be a discussion (perhaps on Disord) to see how feasible they are.

[tresf]

Ok... Reverted 4e76b78. @UnityParadox was accidentally working from msys2 launcher, not mingw64 launcher. Added Important: note to wiki. This should be in good shape. Please confirm so we can close it out.

[tresf]

We have MSVC support on master and the wiki can be improved by anyone willing to fix the msys2 issues (or better yet, a PR). Closing.