Okay, so it’s not a path length issue. FWIW if I try building gperf in classic mode (vcpkg install gperf) I see the same error.
Let me see if I can find an earlier backup of vcpkg and try again.
[Edit…] Oh, one more thing. I’m building with PowerShell here. Is that correct?
Hmmm… gperf builds perfectly with an old backup of vcpkg, so there’s either something wrong with the most recent version of vcpkg or there’s something wrong with the way you’re installing it.
I’ll update my backup to today’s baseline and try just building gperf again.
Okay, I updated my older copy of vcpkg and tried building gperf in classic mode and it gave me the same error. So as an extra check I installed a completely fresh copy of today’s vcpkg and that gives the same error too. So something’s wrong with the latest version of vcpkg 
I’ve reported it as a bug on the vcpkg forum.
[Edit…] Isn’t Ardour’s forum wonderful? It won’t let me add more than 3 consecutive posts so I’ll just have to keep editing this one
After another experiment this morning I realised that if vcpkg is already installed, your python script will use the existing installation rather than downloading the latest code. So I tried again using my old backup copy of vcpkg (from around the middle of May). That one now builds gperf okay but fails a bit later building fontconfig. The error is really weird:-
Found ninja-1.12.1 at “G:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja\ninja.EXE”
ERROR: Clock skew detected. File G:\vcpkg-stuff\gnu-windows\src\vcpkg\buildtrees\fontconfig\x64-windows-dbg\meson-private/coredata.dat has a time stamp 1.2439s in the future.
I guess there might be something weird going on with my system or it’s possibly a processor issue (AMD vs Intel?) The only way to tell is if you make your vcpkg version available somewhere, so the script can install the same version that you’re using, rather than relying on some arbitrary version of vcpkg.
I didn’t take this scenario into account when making the script, but it has the following logic (which was intended in the case of running the script several times in case of unforseen circumstances that shouldn’t repeat):
So yes, it should work.
I’d assume something’s wrong package-wise or vcpkg-wise there. Maybe a version mismatch for dependencies, requiring git pull to fix it? But that would bring you the current errors of the msys2 binutils.
Or, a specific version of one or more packages. And/or, I still have to make and test a custom port for gperf for its latest version.
Sorry Stephen. After realising what the error was I’ve edited my post. Is your processor AMD or Intel? If it’s a processor issue there’s a good chance someone else will need to test this, rather than me.
It’s intel. Also: the python script uses classic mode, not manifest mode.
Edit: The option was wrong. Try manually clearing G:\vcpkg-stuff\gnu-windows\src\vcpkg\buildtrees.
Mine’s Intel too but if you’re building in classic mode doesn’t that mean you can’t use version overrides?
Yes, overriding is a manifest mode thing.
Aaaaaargh! I just got a reply to my bug report at vcpkg. My build issues are because I’ve been building on my G: drive which is the only drive here with enough space left - but it’s not NTFS format!!
Okay… humbled by my rookie mistake I dug out an old USB memory stick (checking it was formatted as NTFS!!) and started again. At first I tried just building from your script (i.e. letting it download the latest vcpkg release) but that still fails, weirdly enough it bombs out while building libffi again!?! So I ditched that idea and switched to my slightly older download of vcpkg which pretty much got everything built. It took a dive when it came to @drobilla’s stuff (serd / sord / sratom etc) with this message:-
Downloading https://gitlab.com/drobilla/serd/-/archive/v0.32.8/serd-v0.32.8.tar.gz → drobilla-serd-v0.32.8.tar.gz
error: curl operation failed with error code 6 (Could not resolve hostname).
error: Not a transient network error, won’t retry download from https://gitlab.com/drobilla/serd/-/archive/v0.32.8/serd-v0.32.8.tar.gz
note: If you are using a proxy, please ensure your proxy settings are correct.
Possible causes are:
- You are actually using an HTTP proxy, but setting HTTPS_PROXY variable to
https://address:port.
This is not correct, becausehttps://prefix claims the proxy is an HTTPS proxy, while your proxy (v2ray, shadowsocksr, etc…) is an HTTP proxy.
Try settinghttp://address:portto both HTTP_PROXY and HTTPS_PROXY instead.- If you are using Windows, vcpkg will automatically use your Windows IE Proxy Settings set by your proxy software. See: https://github.com/microsoft/vcpkg-tool/pull/77
The value set by your proxy might be wrong, or have samehttps://prefix issue.- Your proxy’s remote server is out of service.
If you believe this is not a temporary download server failure and vcpkg needs to be changed to download this file from a different location, please submit an issue to Issues · microsoft/vcpkg · GitHub
It built the previous 140 libraries okay so I wonder if drobilla’s host has changed (or offline maybe??)
Anyway… the 64K dollar question is “what’s the point of all this??” We discovered eons ago that building everything in classic mode results in a bunch of libs which aren’t ABI compatible with Ardour
Tried re-running the script after the error, see if it errors out again?
Only libsigcpp/glibmm/cairomm/pangomm had the ABI issues, other packages were just fine though having slightly different library names or other subtleties that had to be taken into account.
The python script makes use of ports to install compatible versions of those packages which would otherwise be incompatible.
Yes, it didn’t help
For my money I still think that glib/cairo/pango should get added to Ardour’s libs/tk branch and built within ardour (along with their mm cousins).
Would Paul and Robin be willing to introduce a libs/tk-test branch which could get optionally built or ignored? You could then work on getting those troublesome ones to work while Robin and Paul could ignore them until they were proven.
The reason we put gtk2 (or a fork thereof) into our tree was the impending end-of-life for GTK2 on Linux. No such condition exists for glib or cairo or pango.
I think Stephen and I appreciate that but it’d solve a lot of Stephen’s problems (and if it was optional you & Robin could just ignore it…)
My current main problem is to make it easier for others to download the dependencies, and while there’s some logic that vendoring in packages makes installing packages easier by needing fewer external packages, it’s not suitable here, as Paul explained.
I intend on sharing the python script into the forums as a codeblock once its proven to work for anyone other than me. Until then, I suppose things will slow down here for anywhere from a day to a month.
Trying to lighten the mood, @John_E you could try passing --keep-going to the latest vcpkg. As in, editing line 297 of the script to
run([str(_vcpkg_exe), f"--overlay-ports={_overlay_dir}", "install", *packages , "--keep-going"], cwd=_vcpkg_dir)
From the vcpkg website:
Continue the install plan after the first failure.
By default, vcpkg will stop at the first package build failure. This flag instructs vcpkg to continue building and installing other parts of the install plan that don’t depend upon the failed package.
The purpose is to see what package the build fails in after the failure in gperf. If a 2nd package after gperf fails, we can choose to pivot to xmake/xrepo. If not, we know that everything hinges on changing the build system for gperf and no other package.
I added that here but as it turned out, it wasn’t needed (drobilla’s host must have been temporarily offline). Anyway, everything builds fine here now. I can’t get further than libffi if I build from the latest vcpkg but I’ve had quite a few issues with libffi for some reason. Give it a try at your end and if it works for you, let’s just assume there’s something weird going on at my end.
I’m close to done with the xmake path. All mandatory dependencies: Available. Installing them in places that isn’t the cache: Done. And to my surprise: .pc files were generated if not installed from the packages itself, automatically. Saved me trouble I was expecting.
Current problem: Figuring out how to get all transitive dependencies’ files to also get installed, not just the ones listed in the file.
It might be practical for me to just list out all dependencies needing .pc files than relying on the transitive property. I’ll figure something out.
Passed configure step, but the boost includes are a little mixed up. Trying to figure out how to reinstall boost such that includes don’t give errors.
Out of interest, does xmake compile boost or just give you the headers? I was always confused about why vcpkg builds boost as DLL’s. Boost is pretty much all template based so it’s useable just from the header files.