That looks like you’re configuring for Linux/gcc
I think you need --msvc_version="msvc 10.0,msvc 9.0" --msvc_target="x64" for waf (see [1] above) to generate MSVC projects.
and for ardour/windows --dist-target=msvc . see also python waf configure --help
try
python waf configure --dist-target=msvc --msvc_version="msvc 10.0,msvc 9.0" --msvc_target="x64"
I thought otherwise when I saw the output (from running what I mentioned first),
Checking for ‘msvc’ (C compiler) : C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\bin\HostX64\x64\CL.exe
Checking for ‘msvc’ (C++ compiler) : C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\bin\HostX64\x64\CL.exe
(I simply assumed “It sees MSVC, so surely it’s gonna configure for Windows…”)
I decided to try with --msvc_version="msvc 10.0,msvc 9.0" --msvc_target="x64".
The 1st flag alone gave the error,
msvc: Impossible to find a valid architecture for building [‘msvc 10.0’, ‘msvc 9.0’, ‘msvc 8.0’, ‘msvc 7.1’, ‘msvc 7.0’, ‘msvc 6.0’] - [‘msvc 17.14’]
(I assume that’s an outdated flag or something).
The 2nd flag (or the combo of the 1st and 2nd flag) gives the following output,
Checking for ‘msvc’ (C compiler) : not found
Checking for ‘gcc’ (C compiler) : not found
Checking for ‘clang’ (C compiler) : not found
could not configure a C compiler!
The 3rd flag seems to change nothing. Guess it builds for 64 bit Windows automatically. To confirm this, I ran the same command as before: python waf configure --prefix=C:/Ardour2 --configdir=share --optimize --ptformat , then opened config.log, where it said [vcvarsall.bat] Environment initialized for: 'x64'
Before I try to circumvent this by other means, do you think the root wscript should be edited, for whatever this circumstance is?
@EZ4Stephen - tnaugle might currect me but I think it’s unlikely you could build up-to-date MSVC project files using waf. But even if you could, please keep in mind that Ardour itself won’t build using MSVC if your support libraries got built using MinGW (they simply aren’t compatible…) It might work with support libs built using Clang but that’s the big unknown right now…
But in any case, if the support libs got built using Clang, it’d be best for Robin to build them because at least we’d know that everyone’s using the same support stack. There’s no guarantee of that if you build using vcpkg but Robin builds using waf.
No worries, I got the memo earlier.
Anyways, I got the vcpkg package for dlfcn-win32 and got past the error. For some reason I couldn’t get --also-include= and --also-libdir= to work (Those options were mentioned when running python waf --help) (In context: --also-include=C:/dev/vcpkg/installed/x64-windows/include --also-libdir=C:/dev/vcpkg/installed/x64-windows/lib )
What did work, was the following:
$env:INCLUDE = "C:\dev\vcpkg\installed\x64-windows\include;$env:INCLUDE"
$env:LIB = "C:\dev\vcpkg\installed\x64-windows\lib;$env:LIB"
python waf configure --prefix=C:/Ardour2 --configdir=share --optimize --ptformat
…
Checking for function ‘dlopen’ in dlfcn.h : yes
…
I suppose I could do the same thing I did when trying to build for MSYS2. Except the installation of missing packages is a little different.
You need to specify --dist-target=msvc (that is an ardour specific option, and I doubt that it’s auto-detected). When set to msvc, there will be no check for dlopen etc and various required defines are set (e.g. -DPLATFORM_WINDOWS`)
That is great news! So was does find MSVC!
As for msvc_version - So you have MSVC 14.44 and asking for msvc 10.0 is likely the problem. You will indeed have to change the top-level wscript:
Maybe add msvc 14.0 or 17.14 ? or remove the line or try just a single version: conf.env['MSVC_VERSIONS'] = ['msvc 14.0']
It looks like you’re closing in though.
Thank you for the persistence to pursue this issue!
That looks wrong. We don’t use dlopen on Windows and compile may fail on Windows when HAVE_DLFCN_H is set.
You really need --dist-target=msvc which not only skips checking for dlopen, but also sets various other important flags.
not to mention compiler flags
I removed the MSVC Versions line, that worked. To check the other suggestion, I did git checkout wscript. Editing the line to include 14.0 didn’t work. Neither did 17. It had to include exactly 17.14. (i.e., conf.env['MSVC_VERSIONS'] = ['msvc 17.14']
That makes sense. It checked for CL twice though. Not sure if intentional.
PS C:\dev\ardour> python waf configure --prefix=C:/Ardour2 --configdir=share --optimize --ptformat --dist-target=msvc
Setting top to : C:\dev\ardour
Setting out to : C:\dev\ardour\build
Checking for ‘msvc’ (C compiler) : C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\bin\HostX64\x64\CL.exe
Checking for ‘msvc’ (C++ compiler) : C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\bin\HostX64\x64\CL.exe
Checking for program ‘CL’ : C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\bin\HostX64\x64\CL.exe
Checking for program ‘CL’ : C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\bin\HostX64\x64\CL.exe
Checking for program ‘MT’ : C:\Program Files (x86)\Windows Kits\10\bin\10.0.26100.0\x64\MT.exe
Now I have to install the boost headers, and go from there. And yes, with --dist-target=msvc it didn’t look for dlopen (After editing wscript).
You only need the headers (vcpkg package - boost-headers might be sufficient).
Them I’m curious how all the pkg-config checks will work…
There is pkg-config available form vcpkg package - pkgconf - though you may have to set some env variables Support waf and pkg-config? · Issue #1266 · microsoft/vcpkg · GitHub
I was just about to say, I’ve been having trouble. I installed just the boost headers, then did the following:
python waf configure --prefix=C:/Ardour2 --configdir=share --optimize --ptformat --dist-target=msvc --boost-include="C:\dev\vcpkg\installed\x64-windows\include"
The output was the same error:
Checking for boost library >= 1.68 : no
I was starting to doubt whether just the headers would work. Unless I’m on the wrong path, it seems insufficient/wrong.
I see that for prefix you use forward slashes C:/ but for boost backward C:\. could that be the issue?
–
EDIT: the github issue I linked above also use forward slashes.
I guess you could use those for --also-include=$INCLUDE --also-libdir=$LIB?
The established standard on other platforms is to use CFLAGS CXXFLAGS env variable for includes, and set LDFLAGS for link paths. but that may differ with MSVC.
Keen observation. I changed them to forward slashes, but to no avail. I’m like 60% confident I know the reason: Because I only installed the headers ( vcpkg install boost-headers:x64-windows ), there’s no file called version.hpp in that directory ( "C:\dev\vcpkg\installed\x64-windows\include\boost" )
The only file in that directory is “C:\dev\vcpkg\installed\x64-windows\include\boost\headers.gitkeep”, which is 0 kb.
If you’re suggesting I could’ve used the --also… options, it failed for some reason with those options, but these temporary variables worked. (I’ve since then removed the dlopen package though.)
Edit: I seem to have found the version.hpp file in 2 different directories:
Another edit: Neither path worked with forward slashes.
Failed with the temporary variables ($env:… as mentioned above)
Tried with MinGW’s boost path as a last effort for the day, it still gave boost not found.
Tomorrow I’ll probably install the entire boost library, in an attempt to see if the situation changes. Maybe try a few things before it, but still.
To detect boost, a small test program is compiled… and information about that is in the file build/config.log
here (Linux) this looks like
Checking for boost library >= 1.68
==>
#include <boost/version.hpp>
#if !defined (BOOST_VERSION) || BOOST_VERSION < 106800
#error boost >= 1.68 is not available
#endif
int main(void) { return 0; }
<==
[1/2] Compiling ESC[32mbuild/.conf_check_bfc88cc65e61d665f19006adc6a5171a/test.cppESC[0m
['/usr/lib/ccache/g++', '-I/home/rgareus/src/ardour', '-I/home/rgareus/src/ardour/build/.conf_check_bfc88cc65e61d665f19006adc6a5171a/testbuild', '-DINTERNAL_SHARED_LIBS=1', '../test.cpp', '-c', '-o/home/rgareus/src/ardour/build/.conf_check_bfc88cc65e61d665f19006adc6a5171a/testbuild/test.cpp.1.o']
[2/2] Linking ESC[33mbuild/.conf_check_bfc88cc65e61d665f19006adc6a5171a/testbuild/testprogESC[0m
['/usr/lib/ccache/g++', 'test.cpp.1.o', '-o/home/rgareus/src/ardour/build/.conf_check_bfc88cc65e61d665f19006adc6a5171a/testbuild/testprog', '-Wl,-Bstatic', '-Wl,-Bdynamic']
yes
Hopefully the log provides some hints…
I’m not sure that this is relevant here, but in case it helps at any point, I discovered a while back that ./waf configure --also-include=... and --also-libdir=... don’t quite work as documented in the output of ./waf configure --help. According to that, they’re supposed to take a comma-separated list of directories, but actually only accept a single directory each. Here’s the trivial change I had to make to wscript to make them work as documented:
--- a/wscript
+++ b/wscript
@@ -1120,11 +1120,13 @@ def configure(conf):
conf.env.append_value('CXXFLAGS', '-I' + Options.options.boost_include)
if Options.options.also_include != '':
- conf.env.append_value('CXXFLAGS', '-I' + Options.options.also_include)
- conf.env.append_value('CFLAGS', '-I' + Options.options.also_include)
+ for incdir in Options.options.also_include.split(','):
+ conf.env.append_value('CXXFLAGS', '-I' + incdir)
+ conf.env.append_value('CFLAGS', '-I' + incdir)
if Options.options.also_libdir != '':
- conf.env.append_value('LDFLAGS', '-L' + Options.options.also_libdir)
+ for libdir in Options.options.also_libdir.split(','):
+ conf.env.append_value('LDFLAGS', '-L' + libdir)
if Options.options.boost_sp_debug:
conf.env.append_value('CXXFLAGS', '-DBOOST_SP_ENABLE_DEBUG_HOOKS')
Thanks, I’ve just applied that patch, with you as author.
The following command worked to pass the boost test:
PS C:\dev\ardour> python waf configure --prefix=C:/Ardour2 --configdir=share --optimize --ptformat --dist-target=msvc --boost-include=C:\dev\vcpkg\packages\boost-config_x64-windows\include
A few caveats:
--boost-include failed because I put the path ending in …\include\boost instead of …\include.I’m now at the following:
Checking for program ‘pkg-config’ : not found
I’m sure I downloaded it yesterday though. I ran vcpkg install pkgconf again.
I tried using the --also-include and --also-libdir:
python waf configure --prefix=C:/Ardour2 --configdir=share --optimize --ptformat --dist-target=msvc --boost-include=C:\dev\vcpkg\packages\boost-config_x64-windows\include --also-include=C:\dev\vcpkg\installed\x64-windows\include --also-libdir=C:\dev\vcpkg\installed\x64-windows\lib
Still got the error:
Checking for program ‘pkg-config’ : not found
Could not find the program [‘pkg-config’]
Same story after using the two temporary variables ($env:...)
I’ve decided to nuke that vcpkg folder and reinstall it.
It’s probably not relevant but on my system, pkg-config.exe is in C:\Program Files\gtkmm\bin for some strange reason 
Update on removing and reinstalling vcpkg and the packages: vcpkg install boost-headers:x64-windows didn’t come with a version.hpp, I had to do vcpkg install boost-config:x64-windows . (Didn’t remove the files from the boost-headers package)
Also, I didn’t need to add --boost-include..., when I added --also-include=C:\dev\vcpkg\installed\x64-windows\include --also-libdir=C:\dev\vcpkg\installed\x64-windows\lib .
I have a suspicion that the wscript is looking for ‘pkg-config’ but when I install using vcpkg, it gets installed as ‘pkgconf’, hence I’ve been stuck with the following:
Checking for program ‘pkg-config’ : not found
I might have to edit the wscript again. Or someone does it before me.
I don’t seem to have a gtkmm subfolder. Strange indeed.
Thanks for postings this, just built ardour on an old acer laptop (with MSYS2 on a W10 Home install, not sure if that matters for running it on other Windows PCs).
I was compiling it for my children, who are arunning Windows 11 and do not have MSYS2. Would there be a way to find out what I need to copy in terms of ardour-specific and general libraries? My first idea was just a dependency crawler, but that will only show the DLLs loaded at startup.
Thanks!
GTK2 and Gtkmm 2.4 have been “vendored” into the ardour source tree. They do not and likely should not exist outside of it. John must have that lingering around from times past.