Some good points there and I must admit, my experiences with CMake have always been good ones. I’m often confused about the general hostility towards it here. Diff’rent strokes for diff’rent folks I guess.
But I hadn’t heard about the move to Meson and yes, that’d make it a waste of time to be working on waf and Clang. I’ve heard about Meson but don’t know much about it. I’ll do some reading.
Ok, seems to work on Windows with MSVC
and on Linux (Raspberry pi 32-Bit device) it looks like this:
@x42 @paul @BenLoftis - I know Windows development comes up over and over, so sorry to rake it up again - BUT…
Might it be the case that Clang is the link that’s been missing so far? i.e. a compiler that’s compatible with MSVC but with an instruction set that’s modelled on gcc?
I’m wondering if that could be helpful in attracting new developers - what do you guys think?
As usual, we don’t care much… we’re not going to run windows on our builld systems. If someone gets clang working, great. Maybe we’ll use it, maybe we won’t.
There’s zero chance that we will switch to meson. I am not sure what gave anyone that idea.
It came from this disucssion:
Blockquote
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.
So maybe Ardour will see an influx of new contributors after the next banking collapse?
Pretty sure most of those guys develop for Linux, so might not help regarding the current discussion.
Chris - my thinking was that there’s a regular stream of programmers interested in getting on board, though in most cases they seem to want to start off with MSVC. But until now, there’d been no easy way to transfer MSVC skills to either gcc or to the non-Windows platforms.
But I’ve a feeling Clang could offer a route here. So if people could get on board by starting off with MSVC and Clang, at least some of them would likely pick up skills that’d be transferable to gcc and to the other platforms.
Whether that’s useful or not, I don’t know.
Regarding CLANG, i checked it. So far the MSVC and MS-CLANG, FreeBSD CLANG and MacOS-CLANG version all working together in concert with the same code and the same meson.build file, it’s pretty much as good as cmake imho.
Example code: https://github.com/Dravion/meson_test
Screenshots for FreeBSD and MacOS:
@Dravion - I’m also of the view that compatibility between compilers would be a step forward (and a big help for attracting new programmers). But the message I’m picking up here is that any new build system (or new programmers) would only be of interest if they don’t introduce bottlenecks for Ardour. So whereas Meson might give great results for a small build, so did the previous build system (scons).
The view here is that waf and gcc have shown themselves to still be fast - even when dealing with a large and complex project. And that’s very much the acid test.
Yes. But i didn’t pickup meson as build system just for fun. It was my impression that WAF has maybe some sort of drawbacks and there maybe is a desire to implement a new system. As you may know, i personal favored GNU Autotools or CMake. Scons would be fine with me as well.
However: Now i checked MESON myself and it looks like a awesome build tool, which can help to share code between Compilers and between Operating systems as easy as possible. It looks mature and reliable so i was productive testing and checking it out. Maybe it is useful for me in some other projects, i will find out^^
As far as my understanding goes, Paul made it clear that there will be no replacement for WAF (please correct me if i am wrong). I checked WAF as well, but it looks a bit more complex to get it working cross compilers like Cmake or WAF, but maybe i am wrong and i need to learn more about WAF.
With the help of Paul info’s in another Discussion, i was able to build Ardour 8.2 from source with
WAF on Ubuntu Studio LTS. But Unfortently, this was the only distro which worked out. Even the MSYS2 build wasn’t successful in my case.
Yes, WAF is the way to go in terms of Ardour. If i have time i will check WAF next for MSVC, maybe there is a way to make it work. Would be a nice challenge convincing it to do so^^
PS: Yeah, the acid test. A small demo setup to see a build system working is oc not the same as
to build all Ardour dependencies and the program itself. However: I will check WAF for MSVC and maybe it works out, we will see.
Thanks for your ideas and help and have a awesome day.
Here on Windows, Clang produces perfectly good code (and highly compatible code) but I can’t deny it’s a pretty slow compiler compared to MSVC (very slow in fact !!)
So for me, the goal would be to restrict it to the support stack, rather than Ardour itself. Presumably the support stack doesn’t need to get built too often? And it’s just my 2 cents but my gut feeling is that a downloadable / easily available / highly compatible support stack could be quite a help in attracting new programmers.
I suspect the main devs are worried it’ll attract budding, enthusiastic (but mostly inexperienced) programmers… 
Ok, just a little update - now regarding WAF.
It is possible to use it with MSVC, it’s even possible to connect to a Windows box via SSH and let it compile remote on a Win box. Tbh, it’s way less complex then MESON or CMake or Autotools, i was really surprised. To clarify MSVC direct compile via Visual Studio Command prompt and remote Compile just via SSH can be done.
So far, there might be limits i am not aware of, but WAF is impressed bc it’s a clear cut design and
does the Job. Any way, i learned a lot and maybe the findings are of value for some peeoples
Demo code:
https://github.com/Dravion/waf_tests
Regarding the compile and maybe linking speed of the MS CLANG Compiler. Did you enable pre compiled headers for your Project LTCG?
from other systems i experienced very nice clang compile time results so, this is a bit surprising but i didn’t do a lot with MS-CLANG (mainly msvc and the SDK and WinDBG).
In any case, it was fun to experiment with it and learning new tricks 
No I’ve stopped using precompiled headers here. It’s usually quite trouble free for small projects but for a big build like Ardour, PCH was generating monstrous intermediate files approaching 10GB in size!! So I’m afraid that’s one feature which soon got turned off.
In truth, if you’re comparing the two compilers on Windows, you’re unlikely to see much difference between them for those smaller projects - but for the larger builds (e.g. libardour and gtk2_ardour) I’m finding that MSVC will build them in around one-sixth of the time it takes Clang.
I hate cmake with passion, but that is a different story.
If Ardour were to use a new build system, it would be something sane, like meson.
Just to clarify, I wrote this conjunctive for a reason. There are no plans to move away from waf.
Only if someone were to force me at gunpoint to use a different build system for Ardour it would be meson.
–
As for the topic, upcoming Ardour 8.3 (current git) no longer depends on external gtk[mm]2. So you might be able to get all other build dependencies from https://vcpkg.io/
@x42
Is this the complete dependency list?
Maybe putting this list together from the vcpkg.io site you mentioned will do the trick to ease the dependency situation.
Have a look at https://nightly.ardour.org/list.php#build_deps, which is a complete list of dependencies (except for the compiler and bash) to build Ardour and all dependencies from scratch.
With vcpkg.io, you likely only need a subset thereof. You can skip indirect dependencies such as tar, make, bison, cmake (which we need to build taglib and libwebsockets) etc.
Thx. I am already checking it out, let’s see!
Oooh, that could be interesting… even though the ‘mm’ libs need .def files (which makes them very difficult to build now with modern MSVC) I realised a few days ago that Clang is happy to build them all - except for gtkmm!!
Out of interest Robin, how do you currently build your support stack? Is it some massive waf build? Or do the different libraries need different build strategies?
I assume you mean ytkmm 
We use the build-system provided by each upstream library. about 80% autotools, 15% meson and 5% cmake (and bjam for boost).
