Yeah, a boost folder is in there.
In that case I could give you some very simple instructions for setting up that ardourext section in your main include folder - but there’ll be similar requirements further down the line. So if we can’t figure out how to do this kinda thing via waf, there’ll obviously be an impact on the value of your approach - i.e. if other developers wanted to follow it further down the line, but it comes with lots of steps missing 
Good news: I’ve crossed 450/1838.
Bad news: 366 unresolved externals for ytk. (also 4 for ztkmm, but that’s probably easier to solve)
Also, got a few different warnings along the way.
SMF.cc
C:\dev\ardour\libs\evoral\SMF.cc(44): warning C4273: ‘round’: inconsistent dll linkage
C:\Program Files (x86)\Windows Kits\10\include\10.0.26100.0\ucrt\corecrt_math.h(567): note: see previous definition of ‘round’
Sequence.cc
C:\dev\ardour\libs\evoral\Sequence.cc(1498): warning C4661: 'void Evoral::Sequence<Temporal::Beats>::remove_overlapping_notes(void)': no suitable definition provided for explicit template instantiation request
C:\dev\ardour\libs\evoral\evoral\Sequence.h(176): note: see declaration of 'Evoral::Sequence<Temporal::Beats>::remove_overlapping_notes'
C:\dev\ardour\libs\evoral\Sequence.cc(1498): warning C4661: 'void Evoral::Sequence<Temporal::Beats>::trim_overlapping_notes(void)': no suitable definition provided for explicit template instantiation request
C:\dev\ardour\libs\evoral\evoral\Sequence.h(177): note: see declaration of 'Evoral::Sequence<Temporal::Beats>::trim_overlapping_notes'
C:\dev\ardour\libs\evoral\Sequence.cc(1498): warning C4661: 'void Evoral::Sequence<Temporal::Beats>::remove_duplicate_notes(void)': no suitable definition provided for explicit template instantiation request
C:\dev\ardour\libs\evoral\evoral\Sequence.h(178): note: see declaration of 'Evoral::Sequence<Temporal::Beats>::remove_duplicate_notes'
Actually Stephen, this brings up another aspect of my build (targetsxs.h) which might well be the reason for many of your problems…targetsxs.h contains various elements which need to be known when compiling most of the source files - so as such, you’d think it’d be need to be #included in every source.
But the Visual Studio IDE offers a feature called Forced Include where you can nominate a file to be #included for each compiled file - but without you needing to specify it in every single file.
It’s at this point that we need to ask if there’s something similar available within waf? Because if there isn’t, you’re probably on a gigantic waste of time here
What’s the exact string when it’s included so I can look for all files affected, so I can search for the string #include "...targetsxs.h" ?
So you did that with targetsxs.h?
Yes I did do that with targetsxs.h but the important thing is that if you look in any of the source files, you won’t find #include <targetsxs.h> in any of them. The ForcedInclude option is a feature of the Visual Studio IDE. It allows a specific command to be sent to the compiler (for every compiled file) but without the files themselves needing to know about it. Here’s how it looks in the commands when sent to the compiler:-
(your folder location would be different of course! )
What we don’t know is if any such feature is supported by waf 
Here’s what I did to install those older libs. Note that it’s not all code, some things you read and do.
@EZ4Stephen - Have you done much editing of the various wscript files? I never need them for my builds so I’m not too familiar with them, but looking this morning, it seems there’s a “main” wscript file in the top-level folder. AFAICT it defines things which need to be the same, no matter which source file you’re building.
So it looks like that might be waf’s equivalent of the ForcedInclude option, here in my VS IDE. Hopefully someone else here can confirm…
By the looks of things, only yk-pixbuf, ydk, ytk and ztkmm’s wscripts, aside from the root wscript.
Sounds interesting…
I might’ve unknowingly done that:
@@ -1271,7 +1268,14 @@ int main () { return 0; }
# see http://gareus.org/wiki/ardour_windows_gdk_and_cairo
conf.env.append_value('CFLAGS', '-DUSE_CAIRO_IMAGE_SURFACE')
conf.env.append_value('CXXFLAGS', '-DUSE_CAIRO_IMAGE_SURFACE')
- # MORE STUFF PROBABLY NEEDED HERE
+ conf.env.append_value('LIB', 'pthreadVC3')
+ conf.env.append_value('LIB', 'ws2_32')
+ conf.env.append_value('LIB', 'winmm')
+ conf.env.append_value('LIB', 'advapi32')
+ conf.env.append_value('LIB', 'shell32')
+ conf.env.append_value('LIB', 'user32')
+ conf.env.append_value('LIB', 'dbghelp')
+ # MORE STUFF PROBABLY NEEDED HERE?
conf.define ('WINDOWS', 1)
have_int128_support = conf.check_cc(fragment = '''
Thanks Stephen - though I must admit, you’ve confused me a bit…
Maybe @x42 or @paul will correct me - but if you’re trying to build Ardour with MSVC and waf, I’d assume you’d mostly be editing the wscript files, rather than changing its C & C++ source files
The above snippet is part of the main wscript. I added those as a fix for some linking problems for pbd. The pbd wscript is intact.
True - but your previous diff files are mostly listing changes to header files and source files
By chance, have you modified files relating to libs/audiographer to build a little differently for MSVC? It’s saying
LINK : fatal error LNK1181: cannot open input file ‘dl.lib’
And I’m assuming I shouldn’t be having this problem. Rather than make an empty dl.lib, I want to see if I can remove the cause of this when building with MSVC.
It’s probably a different wscript? I don’t know.
My understanding is that dl.lib is normally a Linux library. It provides functions like dlopen() / dlclose() / dlsym() etc. For an MSVC build, it gets declared in one of my extra MSVC files (msvc_pbd.h)
And I’m sorry to keep harping on about this Stephen - but if you keep refusing to implement my MSVC extensions, you’ll either have to implement all this stuff yourself, or your MSVC builds just ain’t gonna work…
Turns out the above problem was due to vamp-hostsdk.pc mentioning dl. Instead of editing that, I edited the audiographer file.
diff --git a/libs/audiographer/wscript b/libs/audiographer/wscript
index 39c54d7941..58f8b33d62 100644
--- a/libs/audiographer/wscript
+++ b/libs/audiographer/wscript
@@ -75,6 +75,8 @@ def build(bld):
audiographer.export_includes = ['.', './src']
audiographer.includes = ['.', './src','../ardour','../temporal','../evoral']
audiographer.uselib = 'GLIB GLIBMM GTHREAD SAMPLERATE SNDFILE FFTW3F VAMPSDK VAMPHOSTSDK XML'
+ if bld.env['build_target'] == 'msvc': #Due to vamp-hostsdk's .pc file.
+ bld.env['LIB_VAMPHOSTSDK'] = [lib for lib in bld.env['LIB_VAMPHOSTSDK'] if lib != 'dl']
audiographer.use = 'libpbd'
audiographer.vnum = AUDIOGRAPHER_LIB_VERSION
audiographer.install_path = bld.env['LIBDIR']
Now I’m at libs/ardour, which seems to have a lot of files…
For now, I’ll continue doing things my way.
We made some progress recently, and merged the first batch of changes to compile libpbd with modern MSVC.
@John_E can we rename your .input files to be proper headers? So far @EZ4Stephen just copied relevant parts directly into each source file, and I have not merged those
Remaining diff: debian Pastezone
I am a big fan of DRY, so a common header to abstract pthread, gettimeofday etc is a lot more appropriate. We just need to find a way that works for a wider audience.
I appreciate that it might simplify things but we need to keep sight of the fact that Ardour has been buildable with MSVC for the past 2 decades so in theory, there shouldn’t be any necessity to modify its source files. In fact a previous dev called Andre managed to build wth MSVC and I don’t recall him needing to modify them at all.
What doesn’t work (currently) is an MSVC build via waf. So my preference would be that @EZ4Stephen should concentrate on modifying the wscript files and as far as possible, leave the source files alone for the time being. Once he’s able to demonstrate a working build, we could then open a discussion about source modifications.
Wow.
Good clarification.
Phrasing it as “as far as possible” might misplace expectations.
Timing of correspondence is an interesting point of discussion, I admit. It’s sometimes hard to assume when’s the right time to send diffs and discuss them. But I do agree that to build and “demonstrate a working build” is the current goal.
Also if you don’t mind saying, what version of MSVC are you on? And have I surpassed previous attempts to build with MSVC via waf? I’ve reached 875/1844, as of this comment.
I believe that once I get the first working build and source files are modified (if necessary), I’ll probably rename my copy of the ardour folder that I got from github and try to build from a fresh clone. I reckon 4 times would be the limit of how many times I start afresh. After all, there will probably be differences in what I have and what’s on GitHub. (Also Visual Studio 2026 Insiders is out, the main wscript would need to include its version number I presume.)
I’m currently building here with VS2022
Sorry Stephen, I’ve no way of knowing
Could you explain how your build links the .dll’s of libs/tk’s subfolders, without needing .def files, if possible? Which .vcproj files are responsible for them? I want to see if there’s something I can copy and implement in waf.