This thread is the most recent discussion of how to build Ardour on Windows using Microsoft-provided tools. The answers are not all resolved yet.
Ah sorry, from the title I thought it was about MSYS2. Will try to find an answer and post it to the appropriate discussion!
hah. That is not helpful at all 
Especially since gtk[mm] is not needed (anymore).
According to the link to I posted above it should be in Bin\pkg-config.exe below where you’ve installed vcpkg. So on @EZ4Stephen 's machine that’d be
C:\dev\vcpkg\installed\x64-windows\Bin\pkg-config.exe
is that \Bin folder in your $env:PATH?
(and yes the package that provides it is called pkgconf).
I should have said “has evolved into …” … you are correct that it was originally about using MSYS2.
That bin folder only has a pkg-conf-7.dll. I did see that .exe in ...\x64-windows\tools\pkgconf (along with the same .dll with the same 70kb size).
Highly doubt it.
Edit: I tried adding the bin directory (and tools\pkgconf) to path with $env:PATH = "C:\dev\vcpkg\installed\x64-windows\tools\pkgconf;$env:PATH” (and similar for bin), but none of them changed the check outcome.
Edit: Taking another look at the path, the .exe was pkgconf.exe, not pkg-config.exe. So, C:\dev\vcpkg\installed\x64-windows\tools\pkgconf\pkgconf.exe.
Try making a copy of pkgconf.exe and call it pkg-config.exe Maybe that’ll help?
2 Likes
I’d been holding back on this, thinking a wscript edit would be better, trying to figure out what edit to make there.
But for the sake of sharing the result, I did it and it worked. To see if it worked without any of the $env:PATH... I closed and reopened powershell, and it didn’t work. So, the combo of renaming the .exe and using a $env:PATH... command does work.
I’ll still try to make a wscript edit. (I wasn’t at my laptop the whole time, so I hadn’t come up with something yet)
Like with meson, CMake and other build-systems pkg-config check is built into waf itself (tech details at [1]).
You could either set PKG_CONFIG environment variable, or copy/symlink the executable as suggested for Windows at GitHub - pkgconf/pkgconf: package compiler and linker metadata toolkit (I expected vcpkg to do that, but apparently not).
You likely will also have to set PKGCONFIGDIR or PKG_CONFIG_PATH to inform pkg-config where to look for .pc files as mentioned there. The “vcpk and waf” issue on github also shows that. something like
set PKG_CONFIG_PATH=C:\dev\vcpkg\installed\x64-windows\lib\pkgconfig
–
[1] https://waf.io/apidocs/tools/c_config.html#waflib.Tools.c_config.check_cfg
I used the following duo to pass the check for pkg-config.
- $env:PATH = “C:\dev\vcpkg\installed\x64-windows\tools\pkgconf;$env:PATH”
- sc C:\dev\vcpkg\installed\x64-windows\tools\pkgconf\pkg-config.bat ‘@“%~dp0pkgconf.exe” %*’
Thanks for the heads up.
Also, installing glib is taking quite a while. I did vcpkg install glib:x64-windows .
Edit: It took 50 minutes, according to one of the last lines of output. Ran the same configure, glib isn’t found. Realized I didn’t set the PKG_CONFIG_PATH variable. Did the following, and it worked.
$env:PKG_CONFIG_PATH = "C:\dev\vcpkg\installed\x64-windows\lib\pkgconfig"
Surely it’s smooth sailing from here… 
Edit: Despite installing glibmm, It says
Checking for ‘glibmm-2.4’ >= 2.32.0 : not found
I ran vcpkg install glibmm:x64-windows again to make sure I installed it correctly, and it gave the following output:
Computing installation plan...
The following packages are already installed:
glibmm:x64-windows@2.80.1#1
Total install time: 1.11 ms
glibmm provides pkg-config modules:
# C++ binding for gio
giomm-2.68
# C++ wrapper for GLib
glibmm-2.68
Sure enough, I check the pkgconfig path, and the file isn’t named glibmm-2.4, but is glibmm-2.68 instead. I’ll continue tomorrow.
Scroll all the way back up…
I suspected that glibmm-2.4 might be a problem. Newer versions break the API.
I cannot think of an easy solution though. Yet since we may also run into this with Ardour on Linux at some point, we could vendor it and include libglimm-2.4 with Ardour’s source-code. Except… pangomm depends on glibmm, so we’d also have to include that.
Maybe it’s a good time to look into this right now, unless you can just build it using the recipe from vcpkg.io just using older source-code, or perhaps you have a flash of inspiration.
I must admit I’m confused now… @EZ4Stephen - when you started this thread you posted screenshots, having successfully built Ardour using MSYS and MinGW. So (presumably?) you were able to obtain compatible versions of glib and glibmm back then. Or did you maybe find pre-built libraries from somewhere?
Does this mean editing the wscript to look for glibmm-2.68 instead of glibmm-2.4 will cause new problems? (Also edited giomm similarly.)
(Lines 1165 and 1167 of wscript, modified:
autowaf.check_pkg(conf, ‘glibmm-2.68’, uselib_store=‘GLIBMM’, atleast_version=‘2.32.0’, mandatory=True)
autowaf.check_pkg(conf, ‘giomm-2.68’, uselib_store=‘GIOMM’, atleast_version=‘2.2’, mandatory=True)
With these changes, I’ve gone past a few more checks.
Currently at
Checking for ‘vamp-sdk’ >= 2.1 : not found
There’s glib2 and glibmm, so I did obtain compatible versions. Though it’s intriguing that I didn’t have the name problem on that occasion, but it came here.
Edit: I’m now at the following.
Checking for ‘rubberband’ : yes
Checking for ‘libusb-1.0’ >= 1.0.16 : not found
Checking for rubberband >= 3.0.0 : yes
Checking for sndfile RF64=>RIFF support : Found
Checking for int128 support : Not found, no int128 support.
Checking for ‘jack’ >= 1.9.10 : not found
Checking for clang : no
Warning: you are building Ardour with SSE support even though your system does not support these instructions. (This may not be an error, especially if you are a package maintainer)
Checking for ‘fftw3f’ : not found
Yes, I think Robin is saying that its API (some function names, for example) got changed so 2.68 will prevent other libraries from working, such as pangomm.
If I follow Robin’s link (to vcpkg.io) it suggests that mere users can add their own libraries (really?) Though if that’s possible, does it offer us a potential solution?
I’ve some contacts at Microsoft so I’ll try to find out if vcpkg still contains older versions of libraries.
Will it come as errors when building, or will the errors be in the final installed files?
I’ve installed libusb in case of a previous error repeating:
I’ve also installed “jack2” from vcpkg, then ran the following:
(gc C:\dev\vcpkg\installed\x64-windows\lib\pkgconfig\jack.pc) -replace 'Version: 1.9$','Version: 1.9.22' | sc C:\dev\vcpkg\installed\x64-windows\lib\pkgconfig\jack.pc
Likewise for ‘fftw3’.
Currently at the following:
Checking for ‘fftw3f’ : yes
hidapi is not yet available for the given system
Checking for ‘aubio’ >= 0.3.2 : not found
It could be either. If function names (or function signatures) got changed, you’ll probably get errors when trying to link to other libraries. But if they’re more subtle changes (e.g. changes to the data in structs or classes) you’ll very likely get run time errors 
I’ve run into a new problem: After running vcpkg install aubio, no aubio.pc file was made in my PKG_CONFIG_PATH (C:\dev\vcpkg\installed\x64-windows\lib\pkgconfig)
Extract from the config.log:
Checking for 'fftw3f'
['C:\\dev\\vcpkg\\installed\\x64-windows\\tools\\pkgconf\\pkg-config.bat', '--cflags', '--libs', 'fftw3f']
out: -IC:/dev/vcpkg/installed/x64-windows/include -LC:/dev/vcpkg/installed/x64-windows/lib -lfftw3f
yes
----------------------------------------------------
Checking for 'aubio' >= 0.3.2
['C:\\dev\\vcpkg\\installed\\x64-windows\\tools\\pkgconf\\pkg-config.bat', 'aubio >= 0.3.2', '--cflags', '--libs', 'aubio']
err: Package aubio was not found in the pkg-config search path.
Perhaps you should add the directory containing `aubio.pc'
to the PKG_CONFIG_PATH environment variable
Package 'aubio' not found
Package 'aubio' not found
not found
Wow, I got a reply back already! That’s VERY unusual 
Here’s what they said…
vcpkg generally tracks the latest versions of libraries. Older versions are not usually maintained once updated, unless you use a specific commit of the vcpkg repository that contained the earlier version (for example, glibmm 2.44). You can do this by checking out the corresponding Git commit where that version was still available.
I’m not sure if that means you can keep older versions of vcpkg somehow. Or if it means you can commit older libraries yourself if you need to keep them. Or if it means you can check out (say) glibmm2.80 and see if git will then let you revert it to glibmm2.44
I was making the aubio.pc file, but got confused on the version. According to aubio Versions | vcpkg.link: Vcpkg Ports and Packages Explorer, the version I got is v2024-01-03#0.
I’ve decided to put it as 0.4.9 since that’s what the latest specified version (that isn’t a date format) was.I specifically ran the following:
$sw = [IO.StreamWriter]::new("$env:PKG_CONFIG_PATH\aubio.pc", $false, [Text.Encoding]::UTF8)
$sw.Write(@'
prefix=${pcfiledir}/../..
libdir=${prefix}/lib
includedir=${prefix}/include
Name: aubio
Description: aubio library
Version: 0.4.9
Libs: "-L${libdir}" -laubio
Cflags: "-I${includedir}"
'@)
$sw.Close()
I do wonder what I’d have to do if I built aubio myself instead of getting it from vcpkg, but I’ll avoid doing that at the moment.
Checking for ‘gio-unix-2.0’ : not found
I expect Ardour will not compile with glibmm-2.68
That is the float (not double) variant of fftw3
That looks like a bug… unix is only for Linux and macOS. Fixed now in git