In my quest to build Ardour using MSVC, I was using newer/latest versions of 4 libraries (at least), namely:
glibmm-2.68 instead of glibmm-2.4
sigc+±3.0 instead of sigc+±2.0
cairomm-1.16 instead of cairomm-1.0
pangomm-2.48 instead of pangomm-1.4
I’ve had to change a few lines here and there in many files to make them compatible with what I had, to make progress in the build. However, the approach I took wasn’t recommended.
I remember some points about RWLock, not using std:: mutex and glibmm/helperlist as some reasons to be building with older libs. And I’m sure that a lot of rewriting of existing code would probably be needed. So for the past 2 days, I’ve been trying to install the older versions. I’ve managed to install glibmm-2.62, sigc+±2.10.2, and cairomm-1.13.1, but have failed to install pangomm - whether v2.42.2 from a tarball, or v2.40.1#4 from vcpkg.
This post is made to encourage discussion on the problems and drawbacks arising from trying to use newer packages when building Ardour. And solutions, if applicable.
There’s really only one solution to this and that’s for Robin (with Paul’s agreement- and probably my help) to release pre-built versions of the Ardour support stack. Assuming the support stack could be built with Clang (which is a big assumption) it’d be the simplest way to attract more developers and the only way I can think of that’s practical.
How long would that take? Asking out of curiosity.
The commands I used to install sigc++, glibmm and cairomm can be found in 3 of 4, no .pc files - Pastebin.com. Note that it didn’t make .pc files, so I’ll have to make them manually. (I’ll probably use a script.) I intend on doing that after successfully installing pangomm.
Well, our build stacks are not useful to people who want to use MSVC. @x42 and I are not going to do any significant work on preparing an MSVC-compatible build stack but we will happily have ardour.org host documented downloads created by someone else.
At least once a year, someone says they are going to (try to) do this. So far, it has not happened. @EZ4Stephen is probably getting closer than anyone so far. The problem, however, doesn’t end there. A downloadable build stack also needs to be updated as we change what we’re using. This means that whoever creates it needs to also ensure that, somehow, it will be maintained, otherwise it becomes useless relatively quickly.
Ardour is highly concurrent, with many high priority realtime threads that read data, and should not take a lock (which is not realtime safe), but the UI modifying data must be be able to lock the data and prevent concurrent reads.
This could be implemented by using semaphores to count readers without blocking them unless some other threads holds a writer-lock, or a RCU.
It’s sad that glibmm dropped it when moving to modern C++. I assume that most other software that use glib/gtk doesn’t have those requirements.
Ardour’s toolkit leans heavily on gtk+2, a central part uses lists (menu, tables…). modern gtk overhauled those completely and then updated the g-* stack (glib[mm], gdk[mm], gtk[mm] etc) accordingly.
Ardour on the other hand had not reason to use the modern equivalent (rather the opposite) for good reasons…
Maybe. For development I tend to build Ardour with whatever the current GNU/Linux system has installed.
Since the goal is to encourage MSVC users to contribute to Ardour they may not need an exact matching build-stack, as long as they can compile and run Ardour.
I think @John_E also uses a rather dated build-stack that he started around Ardour 3.
That’s true. However, the possibility does exist that we upgrade some dependency in order to use a new API that they’ve added. Granted, this has been rare in the past, and is likely to be rare in the future.
I guess that’d depend on Robin’s current MinGW Support Stack. If Robin uses a “dev build” (i.e. pre-built libraries plus header files) then building the whole lot with Clang would be a lengthy job and probably not justified by the small number of MSVC programmers who occasionally want to get involved. But if Robin builds the MinGW support stack himself, it might not be too difficult to try to a Clang build. I think he needed to do something similar when the Mac build switched over to Clang.
There is no Robin’s MinGW stack. Really Ardour can be compiled on various systems on various platforms with different compilers, and I’m not the only one doing that.
And yes most are not interchangeable. OSX/gcc cannot be mixed with macOS/clang.
The compiler won’t make a difference, but clang cross-compiling on Linux for Windows is not on par with gcc, yet. Also natively on Windows it won’t make a difference at all. a compiler is a compiler and entirely unrelated to to the issue at hand. You could also use Intel’s C/C++ compiler.
Besides, I expect potential MSVC devs would like to use MSCV and notably the GUI with built-in debugger, etc.
Just a small update here: I’ve built sigc++2.10.2, glibmm-2.62.0, cairomm-1.14.5 and pangomm-2.42.2. Had to copy some files from the builds, then also had to make .pc files. I’ve not had one mention of <glibmm/threads.h missing. For discussion of my go at building with these, go to the other post ( Building with MSVC, PowerShell. Errors).
Nope, I failed to get pangomm 2.40.1#4 from vcpkg. I think I had to find the hash of the commit or something, then edited one file (Maybe a .json), an deleted another. (A file called CONFIG? Unsure.) I don’t recall everything I did when trying to get it from vcpkg. I manually built all 4 using MSVC nmake.