Windows cross build

Installation & Configuration Windows
#1

Hi, I got Ardour cross compiled after a 3 weeks toil. I took a different approach from building a stack. I used Debian SID and mostly its source package to compile dependencies, which I build creating a .deb file. This way, replication can be quick and the dependencies can be easily kept update.

As I solved the issues of each dependency one by one, I understand why the Ardour team does not advise to make a Windows build. If just a small thing changes or you forget about it, you can easily ruin the whole stack. The official built depends on a dated stack, and nobody dares to touch it, because it would mean pain. Some patches and libraries are no longer available. I suspect the build scripts are pretty “ugly” also, and therefore they are not meant for distribution. And there is no easy way to build a universal and updatable stack.

I found some Fedora projects, which will not build to the end with updated packages. I went almost to the end with that too, but I preferred the Debian approach, as I could use more updated packages.

I tried MXE, but it also needs severe modifications to work properly.

Now, I really feel there is a need for a cross compilation environment that will allow to compile most music software for Linux on Windows. Also the LMMS stack, which is meant for Ubuntu, is quite old. I understand how this should be a project by itself… but it makes no sense to have a software like Ardour without a way to compile it for Windows. I would like something that is cross-platform. I would not use Ardour if I knew that in a couple of years there will be no version for Windows, because the stack became too outdated. So, I think there should be an effort in this direction.

I would like to offer my scripts, if there is interest. Also, I solved the “stack”, but there are still issues. When I launch Ardour, and it goes past the first screens, it seg faults. So, it needs some debugging and maybe some libraries need to be recompiled again. When it will work, I think it will be the most up to date version of Ardour for Windows, and the base to make future builds.

#3

Let me start by saying congrats and welcome to the team of Ardour/windows hackers!

What makes you say that?
It may not use bleeding edge versions of libraries, but the build-stack is regularly updated. There have been more than 35 changes this year alone. Most recently an update of boost. It is not really a pain, but there is usually more fun stuff being involved with investigating 3rd party libraries.

Which ones are those? As far as I can tell the list at http://nightly.ardour.org/list.php#build_deps is up to date and complete. If not please let us know so that we can fix the list or add missing deps.

In case of Ardour, we pick very specific dependencies to provide a reliably working application. This is also why we prefer users to not use a generic distribution build with mostly random dependencies. Using debian/sid (aka unstable) as basis without verifying the state of each dependent library and how it affects Ardour is likely not a good idea.

PS. Regarding “most up to date build”: There are automated (incl. automated build-stack) nychthermeral builds available from https://nightly.ardour.org/ – but currently 6.0-pre, not 5.12.

#4

If you check the versions of the dependencies, they are outdated by an average of 2 years.

Patches that are not available are for example portaudio. Picking very specific versions does not assure long term maintenance. A goal should be to make it work with any source package, unless you include a modified version in the Ardour tree.

SID may be unstable, but don’t forget that I work with the source packages. SID only ensures that I have more update source libraries. Instead of downloading it from a thousand sites, I have one central repository. It’s just an assurance that they will be there if some site goes down.

#5

Picking very specific versions does not assure long term maintenance.

Sorry, there’s just no way I can agree with this. I’m not going to try to convince you otherwise.

Our goal (with regard to building,packaging and distributing Ardour) is to create the best executable package that we can. Our goal is not to fit into what any given Linux distribution is doing at any point in time. That might be your goal, and that’s fine.

#6

I don’t target any distribution. I use source.

#7

I think you misunderstood my point. You wrote:

SID may be unstable, but don’t forget that I work with the source packages. SID only ensures that I have more update source libraries.

I take that to mean that your workflow has a dependence on whatever SID decides to include for its source packages. They can change this at any time, and the next time you decide to rebuild the stack, you get what they give you.

This might indeed be very acceptable and even desirable to someone who wants to build their own version of Ardour for Windows. It’s not acceptable for us, who build Ardour for Windows in order to distribute it to others. We don’t want to deal with what SID or any other externally managed packaging system decides to do about the current version of libpng (or whatever library it might be).

Obviously, if there is a community of people who want to build Ardour for Windows themselves, and they prefer to use your approach, you should all collaborate and do what you feel like doing.

#8

Ok, no problem.

However I think there is a misunderstanding about how SID works. When you do an apt source, you get the original source that was used to build the deb package. You can use Debian patches, but you are not required to. Therefore, there is no difference with downloading the packages directly from the developer’s sites. My build is not dependent on SID in any way. The package management is not used to install binaries, aside mingw-w64 itself. You may know that Debian is very poor in mingw packages and everything needs to be compiled.

I find that SID offers almost the latest sources. Some sources have lesser version numbers. So, SID is not so up to date as one would think.

With the apt source command, you can get the almost latest sources, but apt allows also to download custom source versions (you just append the version you want). This way, you can have some degree of control. And you can always simply use a wget from a developer’s site.

I am not interested in developing a community. I will publish my scripts once completed and they will keep up to date, as they mostly depend on the latest published sources.

You may know that developers cross reference other libraries. Therefore, you may use a stack that is 2 years old, or you may use a stack that is current. But generally you cannot use some dated packages with new ones, as the cross references will break. Therefore, it makes complete sense to build Ardour with the latest libraries available. I feel that this ensures a longer term maintenance frame.

It’s true that I am not interested in the best Windows experience, but I prefer to stick to vanilla sources - always for a thought on maintainability. My goal is max result with min effort with bleeding edge/updated sources.

#9

Hi, I wanted to post an update about my efforts. Despite I could compile Ardour, I was not entirely satisfied on Debian. The latest mingw-w64 compiler with the bintools have some issues with embedded assembly that a couple of libraries have. I realized that it is better to build a toolchain from scratch rather than depend on Debian binaries, and anyway I could not use the most recent libraries of every dependency.

Thus, I gave a try to Arch, and it was a pure delight. Now I have a build that works well with the really latest libraries of every dependency. Indeed, I agree that working on Arch is for very experts and I don’t see a point in publishing all my configurations and files, because without a good dose of tweaking it won’t work straight away. I can share them with the developers team, if anybody is interested, or I can help pointing out bugs. I don’t have really the time to get into coding, but I can help troubleshoot.

There are a few things for which I would like to open a bug request, notably the pbd module failing to create tracks from project files and crashing Ardour. I wonder where is the best place to post this.

#10

Hello, I always experience issues with building a package, because I constantly get an error where it could not fin or read package. Do you know how to solve this? Am I in the right directory?

image
image1891Ă—907 121 KB

#11

Since I wrote that, more packages are included in mingw, so you don’t need to compile them.

Anyway, even if you get to the end, ardour won’t launch correctly. I got better results cross-compiling.

#12

What is cross-compiling?

#13

Compiling from Linux to Windows.

#14

Maybe more clear to say “Using Linux to compile an executable that will run on WIndows” (at least as one example of cross-compiling). In general: building software for one operating system and/or architecture on a different operating system and/or architecture.

This is what we do for the official ardour.org Windows builds.

#15

So you use Linux to compile for Windows?

#16

Oh okay, thank you for your info.

#17

Hello, do you think that Visual Studio theoretically can compile Ardour’s source code? Since msys2 can compile it in theory.

#18

Yes, Ardour can be compiled with MSVC (there is even a .vcproj in arodur’s git tree, maintained by @John_E), the problem is getting all the build-dependencies.

These days many are available via vcpkg.io – but some crucial ones (like gtk2) are not, or need back-porting.

#19

vs-installer-workloads
vs-installer-workloads2906Ă—1456 665 KB

So which of them is needed for compilation? (Not my footage.)

#20

I do not use Windows, and never used MSVC myself.

…but I would hazard a guess Desktop C++. Does that dialog even show when you open the existing .vsproj file?

Have you ever written, or compiled a C++ application?

#21

I haven’t compiled any software yet. Currently, I am using msys2 to compile Ardour, but it currently consumes a lot of time to install the resources. If msys2 fails, then I am gonna use Visual Studio.