A specific problem for Windows programmers is that MinGW totally refuses to join the ‘compatibility club’ (for C++). MSVC and Clang have worked hard to agree about things like name-mangling / struct member alignment etc and their built modules are fully compatible and interchangeable. I regularly build Ardour with some modules built by Clang and others by MSVC and they work perfectly together. But MinGW uses its own preferences and its developers just won’t come on board (I’ve recently been trying to persuade them…)
So why is this important.? Ardour itself is well designed and relatively simple to build - in fact it’s specifically designed to encourage users who want to get involved. But what puts people off is the enormous number of 3rd party libs you need to build before you can even think about attempting Ardour or Mixbus. And of course, many of those libs are older versions now which people can’t even obtain any more.
I’ve argued for a long time that it’d help to attract programmers if Robin could release ‘dev libraries’ for each platform (i.e. pre-built libs, DLL’s and header files). I know from my own experience that I’ve spent months helping devs who wanted to get involved in Ardour development on Windows - but what interested them was ARDOUR development and it was hugely offputting for them to have to build dozens of libraries they weren’t interested in yet. In fact every potential developer gave up because it was just too difficult to obtain and build the support libs
It’d be a huge help if Robin’s dev libraries could be made available - but as long as the build system is MinGW, dev libs just aren’t going to be feasible
As long as i can think of (i had my first real C/C++ experience in 1994 with Watcom C/C++ under MS-DOS/Windows 3.1 and before it was Turbo Pascal v6) the Situation was always terrible, but at least people on average kept things small and up to the task. Regarding Ardour, yes there are so many third party components which easy can crash the entire thing in no time. This is also one of the biggest problems of the nowadays popular NodeJS ecosystem for Webapp Development. Even if you seriously try to create a small, boilerplate project by the book, you already end up with deprecation and code usage warnings, it’s generally not a good state of things.
Yeah, but sorry Jonathan Yong was right in this discussion on SF.
The MSVC CRT Runtime is entirely different and is only compatible to it self, while the GCC
ABI is compatible to it’s self as well. GCC is Cross compiler, it works on many platforms and you
can code on Linux for Windows and even the entire GCC Compiler can be build on Linux and
runs on Windows. The MinGW Project simply added Windows Headers and API Support like
<windows.h> which is also a big benefit to avoid political decision regarding deprecation of Windows API’s and features, enforced by the MSVC Compiler. Imagine you have 5 Million lines of code, update
to the next version of MSVC bc the old one isn’t supported anymore and everything breaks - this is a sad realty with MSVC but MinGW prevents such Disaster for you.
Don’t do it. You get your self in World full of pain if you intermix with entire tool chains.
I also have my experience with all sorts of build systems like you, but besides the technical challenges you also have to have an watchful eye of the often political decisions of the company or team.
Take for example Github. It was bought by Microsoft which was for a long time a arch enemy of the GNU and wider Open Source community and now it’s the new master of one of the most important
Open Source hubs of the world. They try to lure you in some cloud stuff, spy on you and try to vendor lock you.
I also spent countless hours with MSVC and recently MS CLANG. The C Compiler is just ages old
and even fully supports the C89 standard. Once it was a good compiler in the 1980’s as it was a product of a independent Company (Lattice C) but as Microsoft purchased it, all sort of nasty extensions and Language pollution took place. OLE/COM/DCOM/ActiveX/DDL/MFC, WinSDK specific non standard datatypes etc. If you had the pleasure to maintain a large MSVC legacy code base and try to make it somewhat standard compliant you find yourself in a world full of pain, so i try my best to avoid it and focus on GCC and MinGW-W64 C/C++ only.
The same goes by the way for CMake It’s not a bad build system (even if the syntax is strange) but
it’s entirely owned by Kitware. I saw what happens as Microsoft purchased Trolltech and was overnight the new Master/owner of the entire QT-Framework, it was terrifying situation and since this time, i try to avoid using technologies and frameworks which can simply purchased over night by some big fish, and that’s why i avoid Kitware’s CMake. IMHO: Autotools and GNU Make are good enough for the most tasks and still the default standard within the POSIX world It even works perfectly on MSYS2 and Cygwin on Windows. In fact, i also can build MacOS 10.4 Intel/PPC projects if i want to, which shows how reliable Autotools and GNU Make is and that your investment in Developers and this Toolchain is worth the money, now and in the future.
I would also say, its a better investment even for Windows only Software Development to go with MSYS2 and MinGW-W64 entirely. You have no idea what all can go wrong if you change from one MSVC version to another. I had countless encounters over the last 20 years and it was not funny. In 2015 for example Microsoft suddenly started inserting spyware binary code into the closed source, static libs and you had no idea that your own C/C++ App is starting to send telemetry and all sort of spy data to Microsoft servers! I was a big scandal and Microsoft removed it later on but this sort of dirty behavior is something you experience again and again.
Nothing new. Try to build the MySQL server or Apache2 on Windows and you have the same Situation.
Even the freaking Unreal Game Engine has insane internal dependencies and a custom build system, while the Godot3/4 Open Source Game Engine which uses Scons works perfectly and it’s really a complex Software project.
IMHO. A better way to attract and support new dev’s would be to stick to the standard Autotools
and GNU Make toolchain. It’s well established, it runs basicly everywhere and most C/C++ Open Source Developers have to learn and to deal with it at some point.
Building Ardour should as easy as:
./configure
make && check && make install
And if you are fancy, provide a uninstall option for GNU make, It’s easy to do so you can remove the software in a clean way with just make uninstall. Works on all POSIX platforms and even in MSYS2/Cygwin on top of Windows.
Blockquote
IMHO. A better way to attract and support new dev’s would be to stick to the standard Autotools
and GNU Make toolchain. It’s well established, it runs basicly everywhere and most C/C++ Open Source Developers have to learn and to deal with it at some point.
Blockquote
I used Autotools to build an open source project once, I did not enjoy the experience. I don’t consider it to be cross platform since it only really works on “Unix like” platforms. Getting it working on “MacOS 10.4 Intel/PPC projects” should not really be much of a challenge since MacOS 10.4 is a Unix platform and is supported by autotools out of the box. To use it on Windows you have to use MSYS2 and Cygwin which is a cross platform fail IMHO.
I wouldn’t call autotools standard either though it is at least listed as used by C++ developers in the annual developer survey. It was used by about 2% of respondents, similar to meson which is used by the GTK project. OTOH Waf which is used to build Ardour isn’t even listed. I assume it’s in the other section. In comparison, CMake was used by 57% of respondents. I would say that makes it the standard now.
Unlike autotools, CMake works well with all the big three compiler toolchains.
The top 3 IDEs or editors used by C++ developers responding to the survey were Visual Studio Code, Visual Studio and JetBrains CLion (about a third each). Two of those are from Microsoft, all support CMake. Support for CMake is integrated into Visual Studio and is the native project model for CLion.
GNU/Make is unsuitable for a project this large. waf can scan over 1500 source file dependencies in way under a second. This is significant for development (when you compile Ardour a few hundred times per day) and the main reason why we chose waf (among other reasons are notably that it is standards compliant, allows to use custom python code to handle edge-cases, and that waf is self-contained and reliable).
Blockquote
GNU/Make is unsuitable for a project this large. waf can scan over 1500 source file dependencies in way under a second.
Blockquote
Waf was created for the KDE project because SCons was considered too slow. However, KDE decided to adopt CMake. Qt ultimately also decided to use CMake.
I agree that the performance of Waf is very good for large projects. The problem is it is not supported by the common C++ IDEs and lacks widespread use and adoption.
Ardour used scons in early days (ardour2), as well.
We definitely won’t do that. I hate cmake with passion, but that is a different story.
If Ardour were to use a new build system, I would be something sane, like meson.
Besides, Ardour’s build system is by far not the bottleneck that prevents new devs from contributing. C++ developers experienced with massively multi-threaded, realtime-constrainted programs are rare (and usually work in high-speed trading).
Pidgin3 uses Meson and it’s also very messy. The count of different languages and libs in Pidgin is even worse then Ardours dependency count and find meson not a better build system.
I never experienced any Autotools limitations, even for extreme large projects like PostgreSQL, it just works. Regarding CMake, it’s not bad but if someone acquires Kitware, you don’t know what hapend’s next to your project.
Dravion was making a good point that (in the past…) it was often a nightmare trying to mix & match code created with different compilers but my point was that MSVC and Clang have shown that this needn’t be the case. It’s not just that they work together on Windws. They work together exceptionally well.
It’s not so much the limitations of autotools as the fact that the build system is not part of the project, and the autotools system has been notoriously non-backwards and non-forwards compatible. This forces every developer to be required to have more or less precisely the same version of autotools … which is possibly fine if they only build Ardour, but if they build anything else there’s a solid chance that it will be the wrong version for that other project.
We ran into this problem endlessly before we switched to scons (and then later waf). We are NEVER going back autotools.
Note that C++11 threads API is useless for Ardour since there is no standard API to set thread priorities or time constraints.
There are no plans to support CLAP, since clap’s killer feature is polyphonic modulation and Ardour has no UI for it. Everything else is also supported by other plugin standards (notably LV2). So right now there is no benefit to users if Ardour had CLAP support.
But if someone wants to work on adding CLAP for Ardour regardless that would be welcome.
Blockquote
Pidgin3 uses Meson and it’s also very messy.
It seems a very new build system based on what I have read. I did read that they had added a way to integrate upstream dependencies that rely on CMake as a build system.
Blockquote
Regarding CMake, it’s not bad but if someone acquires Kitware, you don’t know what hapend’s next to your project.
I could see Microsoft acquiring Kitware, they already acquired GitHub and created vcpkg, an open source package manager that integrates with CMake.
Yes, Microsoft was suddenly also the new owner of the QT Framework when they aquired Nokia and Independent Devs really got the panic bc nobody knew what will happen next, espacially as the then Microsoft Boss talked openly about letting it die or getting rid of it. Finally it got sold to Digia Inc. but this really teached me a lesson.
Regarding Meson i used it to build Pidgin3 and i noticed it depends on Java for something and it felt a little bit like a re-incarnation of Apache ANT and Maven. However: Oracle Aquired SUN+Java and immediately started Patent trolling and suing other Companys for using Java not in “the right way”. Yes there is OpenJDK but its not available for all Operating systems and for Windows you would then need the Oracle JDK which i believe isn’t Open Source any more (there where a license change after Oracle JDK v12 i believe).
Technically spoken, Java is a hugh Platform with many strange behaviors, it doesn’t make things easier if you integrate something like this to the mix. Once i had a Day Job in finance, doing Java programming and i remember it was incredible slow and bloated, but maybe it got better.
Update:
I checked the system requirements for Meson and it says it depends on Python and Ninja, not on Java, maybe my case was Pidgin3 specific.
OpenJDK is available for Windows. The Java ecosystem does have a lot of very bloated libraries, Spring being an excellent example, but it has some well written ones too. It also has only two common build systems and both have excellent dependency management.
The .NET ecosystem is similar to Java in many respects but with one build tool and one package manager. It is technically open source though Visual Studio is not and some of the VS Code .NET plugins are also licensed. That is the concern with MS owning Github and potentially buying Kitware. OTOH CMake is distributed as an open source product with a BSD license (Qt was not). When Oracle bought Sun, it didn’t just buy Java, it also bought MySQL. The community wasn’t happy so it forked MySQL and the fork became MariaDB. The same thing happened with the Hudson CI system. That forked and became Jenkins.
I like that both CMake and Vcpkg are native apps that do not require a Python or Java environment to work. The bigger advantage though, is the level of support CMake gets from the compiler and IDE developers in the C++ working in the C++ ecosystem.
This thread has now diverged subsantially from its original intent, and several years of cogent contributions. I am going to lock it to stop the continuing spiralling away from the topic.
