MSVC Dependencies: Update [As of Feb 2026]

Installation & Configuration Windows
#81

I was also getting similar warnings from my research. I ended up dropping glib and pango from xrepo (though it might come anyways as a dependency of something else?)

Current state of the script:

add_rules("mode.debug", "mode.release")

add_requires("libsndfile")
add_requires("curl")
add_requires("libarchive")
add_requires("vcpkg::liblo")
add_requires("taglib")
add_requires("vcpkg::vamp-sdk")
add_requires("libusb")
add_requires("vcpkg::rubberband")
add_requires("jack2")
add_requires("fftw")
add_requires("vcpkg::aubio")
add_requires("vcpkg::lv2")
add_requires("libxml2")
add_requires("cppunit")
add_requires("libwebsockets")
add_requires("portaudio", {configs = {asio = true}})
add_requires("libsamplerate")
add_requires("vcpkg::serd")
add_requires("vcpkg::sord")
add_requires("vcpkg::sratom")
add_requires("vcpkg::lilv")
add_requires("boost")
add_requires("conda::libsigcpp 2.10.8")
add_requires("conda::glibmm 2.58.1")
add_requires("conda::cairomm 1.14.4")
add_requires("conda::pangomm 2.42.1")
if is_plat("windows") then
	add_requires("pthreads4w")
	add_requires("wingetopt")
end

The only dependency that seemingly no package manager (that can be used on Windows) has, is lrdf, but that’s a concern for later.

Also removed libpng as it will be built as a dependency to cairo.

#82

Seems like I can install only one of release and debug at a time. I assume I’ll face problems when trying to install the debug variants (at least because of Conda), but I’ll first test building Ardour after this is complete.

image
image584×615 18.5 KB

#83

It’d be good get Robin’s input here. I’ve always assumed (perhaps wrongly) that Robin’s debug builds might be linking against his release builds of the support stack? The main reason it’s always intrigued me is that the runtime performance of Robin’s debug version isn’t that much worse than his release version. Whenever I produce a debug build with MSVC (using debug versions of everything) the runtime performance is utterly abysmal :anguished:

#84

Turns out suitable versions of glibmm from Conda are not supported on Windows.

So we’ve fallen back to the old problem of sourcing older versions of libsigcpp + glibmm + cairomm + pangomm for Windows (MSVC).

While the python script worked earlier, that can be temporarily ignored. The package managers that support Windows with MSVC are Xrepo, vcpkg, conan and conda. Conda can be ignored since it’s only release builds, leaving Xrepo, vcpkg and conan.

Vcpkg: Already had difficulties trying to install older versions
Conan: doesn’t have a suitable version of glibmm (lowest is 2.66.0)
Xrepo: Untested.

Of the three, if you consider the range of dependencies available if those 4 are excluded, Vcpkg has the most coverage, followed by Conan, then Xrepo.
(One person has put in a pull request for rubberband to be added to Conan recently, too. So there’s progress there.)

To me, the right follow-up move seems to be to try making custom ports/recipes in vcpkg (done before), conan (done before but I didn’t upload it online), or Xmake (not done before, and not sure if they have all dependencies for it, but I can make it work.)

Currently doing a little digging into whether Xmake allows using custom vcpkg/conan ports. Seems like a yes. So I’ll probably look into my old vcpkg ports and see if they need any changes to be used to build those 4.

WSL GTK2 Issues
#85

Looks like you’re on the right track. This looks very similar to homebrew, or even debian’s dependency list (!)

#86

My attempts of using the port overlay failed at pango for some reason. I suppose I’ll pivot to submitting build recipes to xrepo (and 1 or more to Conda as well, though that’s inherently release only.)

Well, Xmake does allow getting packages from Homebrew as well. (if the link doesn’t take to the right section, Ctrl+F “supported package”.) Not sure if that influenced Xmake’s syntax.

On a side note, perhaps it’s worth mentioning Xmake seems to have a lot of functionality aside from package management. (This can also be viewed from the hyperlink in this comment, by scrolling to the top)

image
image929×231 10.3 KB

One thing that feels different though, is no indication of prohibition/discouragement of requesting older versions of packages to xrepo.

If anyone was/is considering submitting recipes/ports to any package manager to help me, I’d recommend doing so for xrepo: Issues · xmake-io/xmake-repo · GitHub .

image
image310×594 29.1 KB

image
image284×636 28.7 KB

#87

@x42 Hi Robin. I’ll soon be drawing a line under this but in case it helps, I spent this morning with vcpkg, trying to establish which of the above were the earliest versions I could build successfully:-

sigc++: vcpkg doesn’t offer anything at all from ver 2 so I wasn’t able to test it
glib: earliest buildable version here == 2.80.0
cairo: earliest buildable version here == 1.18.0 **
pango: earliest buildable version here == 1.48.4
glibmm: earliest buildable version here == 2.80.1
cairomm: earliest buildable version here == 1.18.0
pangomm: wasn’t buildable here ***

** cairo gets built using Meson (which has very poor support for backwards compatibility) so ver 1.18 is in fact the most recent version available from vcpkg.
*** pangmm is a weird one. It also builds with Meson and apparently needs version 2.56.1#1 (again, the most recent version). But 2.56.1#1 isn’t available in my vcpkg repo. I assume it might be available if I updated vcpkg but if so, this’ll be an ongoing issue for anyone trying to build with vcpkg.

So IMHO, for ‘glib’ thru ‘pangomm’ if any of those versions aren’t compatible with Ardour, your best option would be to abandon vcpkg and hope that Stephen can find more suitable versions in some other package manager. Or a better option… migrating the appropriate versions into Ardour by extending ‘libs/tk’ to build those particular ones.

But as Stephen’s already hinted, it’s definitely looking like sigc++ will be the “elephant in the room”. Have you thought about modifying Ardour to see if it can use sig++ ver 3?

#88

Yes, I have. That’d me a major task, and also require us to patch ytkmm (aka gtkmm) which heavily uses sigc++2, not to mention Ardour’s main UI. In turn we’d also have to use modern versions of all the other *mm libraries.

It’s not something we’re prepare to do anytime soon, if ever.

#89

I’ve just realized that I should probably have prioritized adding the xmake.lua files for libsigcpp + glibmm + cairomm + pangomm to xrepo!

[For reference, liblo had already been added (I made one commit, and a maintainer did the rest for that), and I’ve already made PRs for a few others (though some platform specific edits here and there might be needed).]

libsigc++ down (at least the main edits), other 3 to go. Per past attempts, building glibmm will be the hardest unless the constraint of glibmm needing helperlist can be removed.

#90

That’s an interesting observation… I haven’t looked into other package managers but quite a few of the libraries in vcpkg use libsigc++ so clearly they must all be using sigc++ ver 3. In which case… might that explain why “our versions” of those libs (being older versions) aren’t available from vcpkg? Because if that’s the case - and some other package manager also doesn’t include sigc++ ver 2 - there’s a good chance that they also won’t feature earlier versions of the *.mm libs either :anguished:

#91

This morning I decided to check (in vcpkg) which libraries use libsigc++ and the news is VERY encouraging… for the libraries that Ardour uses, only 2 (within vcpkg) actually use libsigc++:-

  1. glibmm
  2. cairomm

and therefore…

Theoretically Robin, if you could adopt my suggestion to extend ‘libs/tk’ by introducing glibmm / cairomm and pangomm (plus their non-mm equivalents) - AND - if Ardour itself could build libsigcc++ version 2, that should solve Stephen’s problem (i.e. everything else can be obtained from a package manager).

I’m a bit surprised that Stephen hasn’t implored you to consider that :grinning: 'cos assuming it wouldn’t be detrimental to your other builds, that’s definitely the solution here.

#92

There’s a concept I’ve learned called segregation of duties. Applying that to Ardour, I don’t want to unnecessarily vendor a dependency in. Let package managers handle the ability to get dependencies that aren’t vendored in. Other possibilities have not yet been exhausted. And given I’ve managed to build those 4 before (though not easily enough), surely the idea to vendor in any of those can be avoided?

And hypothetically, if it did get vendored in, it would not likely be a smooth process, and implementing that will take away resources compared to doing anything else. And people’s existing solutions to get all dependencies would need to drop those 4 from (if they’re not like, available without needing to be manually installed).

And if it were vendored in only to be used by MSVC builds, that would feel like a short-term fix that unnecessarily takes up disk space on non-msvc builds (which virtually is everyone except you and me, currently.) If anything. Doubt that’s the right way to go.

Think of and compare to the ideal scenario where one can build those 4 dependencies easily: All of a sudden, the effort into vendoring in those packages just for MSVC builds becomes redundant.

So TL;DR, I wouldn’t implore that.

On a side note, you did have copies of those 4, + other dependencies, right (regardless of whether from vcpkg)? And do you have llvm-nm somewhere with the Visual Studio installation? Asking for the purpose of attempting to build Ardour with waf using msvc.

#93

There’s one dependency here (pthread) where I use the pre-built version and I think there’s another one but I can’t remember which one. And I don’t seem to need llvm-nm here (is it maybe some external utility?)

#94

For the waf build, llvm-nm is needed to generate .def files. Use the installer from Release LLVM 22.1.4 · llvm/llvm-project · GitHub if you don’t have it.

As for pthread, perhaps copy the files from vcpkg to where your existing libraries are kept?

Also, do you have pc files for the dependencies?

#95

No I don’t need pkg-config for my builds although I just found llvm-nm here (it’s a utility within Visual Studio but I don’t need to build it).

I’d be happy to try the pthread experiment for you, but what’s the reason?

#96

To attempt building with waf immediately using your existing set of packages, and see what errors you get!
The configure step depends on .pc files for finding existence of (most or all) libraries.
If you don’t have .pc files, might as well not attempt just yet. Just linking the fact that you had most(?) dependencies already, theoretically.

#97

I do have all the dependencies here although I build them myself (not very often, but occasionally). Unfortunately though, I’ve never used waf so I’d probably see lots of errors just because I’m not familiar with it :grinning: