Win64 MinGW64 MSYS2

[defcronyke]

I don't know a lot about Windows dev, but I was able to build the latest Ardour on Windows 10 MinGW64 MSYS by following these carefully crafted steps. All existing examples of how to build Ardour on Windows were broken or incomplete, so I put this one together.

[mojofunk]

Thanks for your interest in participating in Ardour development on Windows.

As one of the people involved with developing Ardour on windows I'm not convinced that adding this information to official repository is a good idea as it indicates that your instructions are supported by other developers or you should have a clear disclaimer at the top of the README file that any builds are unsupported etc.

Also, I would not merge these changes as is for these other reasons:

You should squash both those commits into a single commit.

MSYS and MSYS2 are two very different projects and it is MinGW-w64 so you should fix the commit message.

I think an appropriate place to add this information would be tools/msys2 not mingw/

Most of your README.md should really be a script/s. install-build-deps.sh etc

Using JACK with Ardour on Windows is no longer the officially supported audio backend on that platform. You should mention that it is optional and unsupported.

You should not patch the build system or code but rather submit patches/changes that work on all platforms(we can help you with testing on the other platforms)

[x42]

I second @mojofunk 's suggestions: Either make it a script on tools/msys2/ or a doc/unofficial_msys_build_information.txt.

I'd even make the last line stronger: "You must not patch the build system or code". Code-changes should become #ifdef (there are already plenty for MSVC and MINGW cross-compile builds) and there's compiler_flags_dictionaries in the top-level wscript for system-specific compiler options.

The current doc is a good start however, most info is already in there and just needs to be moved to the right place.

As for detecting the libraries, it looks like this is a pkg-config setup issue on your build machine. It'd be great to track this down: Some hints to get started: pkg-config.exe --list-all, search your disk for glibmm-2.4.pc, pkg-config --debug --exists glibmm-2.4 ..

Curious, why does libclearlooks.la not compile on windows with msys?

Figuring out how to compile Ardour and build-dependencies from scratch has traditionally been the "entry level exam" for new code contributors, I suppose we'll have to re-think that now. Then again you're not starting from scratch.. :)

[defcronyke]

Thanks for the feedback, I will do these things which are suggested soon. I wanted to get the currently working steps down in writing first (i.e. the README.md), and doing a proper set of changes to Ardour would be harder, so that will come next. I agree with all the suggestions.

I think some things weren't detected by pkg-config because I was running ./waf configure in the MSYS2 shell instead of the MinGW64 MSYS2 shell. After running the configure in the MinGW64 shell, many more things were correctly detected, so that list of sed commands can probably be much shorter.

Clearlooks does compile, but then there is no text showing on the buttons (the buttons are white background with white text). I got the clearlooks workaround from Guy Sherman's original post. If there is a correct way to build the clearlooks with the right theming, that would be ideal.

[defcronyke]

I made some of the suggested changes. I think making scripts out of it would be a waste of time, time which would be better spent adding actual "compile on Windows" support into Ardour. I'm not sure that I'm the best one to attempt adding the support, but if no-one else does it, I may try at some point.

Can we add these instructions though for now, in the hopes that it may make someone's life easier if they want to add proper Windows build support later? Then anyone who doesn't want to wait can run these hacks in the meantime to get Ardour built.

[defcronyke]

I decided to make the scripts, and I'm testing them now with a clean MSYS2 prefix to quadruple-check that they are working. Will update the PR when the scripts are ready.

[x42]

cool. Thank you for stepping up and following up.

[x42]

The libclearlooks.la file is only meta-data (how to link). It isn't even necessary for resulting binary (it's currently copied into the installer by accident)

Can you do a diff of the file that msys2/mingw generates vs the one from the ardour-bundle (mingw x-compile) maybe it's just dlname='libclearlooks.so' vs libclearlooks.dll or something similar set by configure.

[defcronyke]

$ file libclearlooks.la.orig libclearlooks.la
libclearlooks.la.orig: libtool library file, ASCII text
libclearlooks.la: PE32+ executable (DLL) (console) x86-64, for MS Windows

The "orig" is the one from MinGW.

[defcronyke]

I put together a set of scripts which almost fully automate the Windows build process. I'd love to get some feedback on this, and would appreciate any help or advice for making it better. I'd also be willing to maintain this unofficial build process and attempt to update it to work with any new Ardour releases that happen to have a broken Windows build process, like 5.4. Let me know what you think of it.

[x42]

re clearlooks:

https://github.com/Ardour/ardour/blob/master/tools/x-win/package.sh#L146

[x42]

Very nice, that looks a lot better.

Can you make the URL a variable? e.g $URL instead of hard-coding
raw.githubusercontent.com/defcronyke/ardour so that this can become ..github.com/ardour/..

I suppose it's a bit of a chicken/egg. and squared if the scripts also come with ardour-git itself again.

[defcronyke]

Okay no problem, I am working on it and will update the PR once some variables are added.

[defcronyke]

Oops, I didn't mean to close this.

I added some variables, let me know what you think, and I'm still willing to improve it further with any suggestions.

[mojofunk]

I still have issues with this pull request but I don't have time to respond fully at the moment.

I think the main issue I have which I did not mention previously as I was not sure how committed you were is that most of those MSYS2 packages that you are building: jack, liblo, lv2 stack etc are packages that I wrote when I was building Ardour using MSYS2/mingw.

There were two reasons I stopped building Ardour on msys2. The first was that it was much slower than just cross compiling and copying it across the network (but that isn't really relevant). The second is that MSYS2 is basically a rolling distribution and was at least over the period that I was using it had rapidly changing dependencies which I found less that ideal. I have not maintained those packages since I stopped using MSYS2 and as such were pretty much un-maintained when Guy Sherman used them to build Ardour more recently using MSYS2.

So if these scripts gets added to the master branch I feel like I'm indirectly responsible for any issues that arise. Most of those packages are old versions and would need updating. The JACK package that you are using to link to libjackd was only for ever used for testing and I never used it to communicate with a system wide jack2 install as it is a different version, probably compiled with a different compiler and that is just asking for problems IMO.

So I would at least like to see all those packages updated and added to the official MSYS2 package repository before I would feel comfortable approving a set of scripts like this. Other developers may feel differently.

[defcronyke]

Hey @mojofunk, thanks for the feedback.

The scripts are tested on a clean MSYS2 prefix, and working. I have forked Guy Sherman's MINGW repo in case I need to make any changes to it, but so far there aren't any necessary because it works, so the scripts are still using Guy's guypkgs branch for now.

I am willing to support this method as needed. if you make any changes to your MINGW repo, I can pull them and switch the scripts to use my fork by default.

I am mostly interested in supporting the latest Ardour release versions, so I don't really care if older versions break when they become outdated, e.g. because the MSYS2 packages are too new. I come from an Arch Linux background, so I am right at home with MSYS2 since it's rolling-release like Arch, and even uses the same package manager.

I can also submit PRs to the MSYS2 repository if necessary. You don't need to be responsible for it at all.

Setting MAKE="make -j" makes everything compile really fast on Windows 10. It uses all your cores, and maybe it's slower than Linux, idk, but to me it seems really fast.

[x42]

I can also submit PRs to the MSYS2 repository if necessary

Now that you mention it. How about getting this Ardour build script in there?

Generally Ardour-git itself does not include downstream build-stack/build information, because that is specific to the OS/distribution at hand. The cleanest solution would be to actually include it in msys2. Much like Arch's Ardour package.

[defcronyke]

The point of this for me is to make Ardour from the official repository, Windows build friendly. I want to be able to build as close as possible to the latest master branch version, but I tried targetting master a bit and it drove me insane :P

So I can target new release versions where necessary, and I'm willing to try to keep up with that, but the code contribution is intended for Ardour and not MSYS2. I trust Ardour and its devs, and I don't know anything about the history of MSYS or MSYS2, and really if I was packaging for MSYS2, I would make a PKGBUILD instead.

This build method is meant to give Windows users an easy way to install a version of Ardour that they could develop on. I will use it personally, and I hope it can also be useful to the Ardour community. I really wanted to contribute something to Ardour, since I am a programmer, and a musician who has used Ardour on Linux for many years.

[x42]

As far as I can tell, the only relevant part for Ardour itself is in 04-patch.sh
The rest is just build-dependencies & build-environment, is that correct?

[defcronyke]

Yes exactly, the rest of it is general enough to apply to any msys2 software, and can be fully customized through ENV variables to do almost anything.

[guysherman]

I'm thinking about using the Windows Subsystem For Linux instead of MSYS2. Theoretically this should work exactly the same as using the cross-compilers from a linux box. I'm wondering if anyone has the scripts for building the dependencies in the cross-compile environment. The other nice thing about it is you can invoke it from the windows command line using bash -c, so for instance you could invoke it from an IDE or advanced text editor such as Atom, or Visual Studio Code.

[x42]

x-compile is pretty much identical, except the build parameter for configure:
./configure --build=x86_64-linux --host=x86_64-w64-mingw32

[defcronyke]

@guysherman This sounds pretty cutting edge, I only just heard about it yesterday. Let's work together more closely to add better Windows compiling support to Ardour, even if we don't use the stuff from this PR. The PR was intended more to document the deps and patches etc, for developers who wanted to help with Windows support, and I wouldn't have been able to make it without your tutorial.

[guysherman]

@defcronyke Sure thing. Ostensibly the biggest challenge will probably be building all the dependencies, but since the ardour build servers do this as needed when they build for windows, it is clearly possible. @x42 Are the scripts for cross-compiling the dependencies in the/a repository?

[x42]

@guysherman There are some cronjob shell scripts on the build-server but they don't have a license header. So I don't know what to do. In any case they're messy and depend on debian/cowbuilder for some circular dependencies. You're probably better off writing something that trying to read/modify those.

An early attempt which may be handy for inspiration: 6600cf0daa

[guysherman]

@x42 noted. Will take a look, thanks.

[defcronyke]

@x42 do you think it would be worthwhile for us to attempt adding jack1 support to Windows? We are interested in that since jack1 seems to get more dev time from the experts.

[pauldavisthefirst]

Is there anything of value in this PR at this point? I've read over the discussion, and am unclear whether there's anything here to be used, or whether the net result is "hmmm...."

[defcronyke]

Thanks Paul, you're right, there is nothing left of value in this PR. Alsa seems to work well, and Ardour is too buggy on Windows right now anyway, so people should just pay you for the stable version for Windows, because it probably takes a lot of effort to make it somewhat bug-free. Let me know if you want any other help with ardour though, I could help on the Linux side for simple stuff like GUI features or something.

[x42]

Re-reading, this is pretty much separate project.
Like other build-recipes (e.g. macOS[X]' homebrew, various linux-distros...) it encompasses Ardour. It's not part of Ardour's source itself (chicken/egg).

[bird0912]

Hi Guy, I am new in this world of building open source programs, and I really want to use Ardour on mi Windows 10 64bits. How can I "easily" compile de code with MSYS2?
Thanks for the help and excuse my inexperience
Good morning :)