Windows cross build


(Fabrizio del Tin) #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.


(Robin Gareus) #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.


(Fabrizio del Tin) #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.


(Paul Davis) #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.


(Fabrizio del Tin) #6

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


(Paul Davis) #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.


(Fabrizio del Tin) #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.