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).
Usually work in high-speed trading
LOL. I did that back about twenty years ago, when my big problem with the Windows machines wasn’t compilation, but the fact that if I pushed trading-volume data to them (including deal valuations), the networking stack would fall over, locking the machine up hard enough to require a full power-off. We had identified that as a risk during integration testing, but (surprise, suprise) the traders were all “No, I have to have that data as fast as possible! You can’t throttle my feed!”
@x42 - Robin, presumably you’re linking to gtk & gtkmm statically now? In which case I might try doing the same here at the weekend - but can I just check something first…?
Are you assuming that a static build will be okay because gtk & gtkmm will only ever get used within gtk2_ardour? 'cos that doesn’t seem to be the case for my builds. libardour, clearlooks, widgets, gtkmm2ext and a few others all seem to be dependent on gtk or gtkmm.
Unless they’re maybe old dependencies that I should’ve removed long ago !!
As far as i know *.def module definitions are a thing from the past. It is even today possible to declare the function and variable exports for DLL’s with it but it’s rarely done in current times.
Today it’s most declared inside the *.cpp or include headers like this:
// Inside the DLL / *.h / *.hpp
__declspec(dllexport) void MyFunction();
// The App which needs access to the external DLL *.c / *.cpp / *.cxx file
__declspec(dllimport) void MyFunction();
I am not pretending to be the “know it all” guy but this is how i understand it
@Dravion - you’d probably be right if we were running with newer versions of the ‘mm’ libraries but Ardour uses quite old versions - from when they were still needing module definition files.
BTW (for Robin) are you able to do a full Debug build at your end - including the support stack? I tried some initial experiments here, with Mixbus rather than Ardour. But running with gtkmm as a static lib doesn’t look good here. It compiles and links okay but at runtime I just see a bunch of assertion messages and MB fails to launch. I’ll dig a bit deeper tomorrow when I’ve a bit more time.
No. we’ve just copied the gtk2 sources into Arodur’s source tree because some GNU/Linux distros are dropping GTK2. After that we’ve thinned it out and removed everything that Ardour does not need and applied a few Ardour specific patches.
From now on treat it like any other Ardour specific lib (libpbd, libardour, libevoral etc) which are dynamically linked.
–
PS. I don’t believe it’s possible to statically link gtkmm/gtk since that would effectively require statically linking the whole application with all other dependent libs.
But theoretically, it should be possible to build a Linux/Unix shared object (.so) or a Windows Dynamic Link Library (.dll) which stands alone and has all static stuff in it self. Yes, the DLL or SO would be quite big but it should be possible.
There are various issues with static linking GTK, manly multiple dllmain or in the un*x world .init and .fini methods. glib implements it, as do atk, gdk, and gtk (and probably a few more). You’d have to modify all those libraries and combine the static initialization. Furthermore GTK dynamically loads modules at runtime…
So while theoretically possible to patch everything, sequence initialization and statically link the whole things, there is no real benefit of doing that.
Ok, ok - i said nothing.
That sounds awful^^
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.