No, the -k shared should mean this gets built as shared.
I concur, and I’ve had to deal with this when submitting some packages. But from xmake’s side, it appears to be -k static/shared (or --kind?), with the default if not mentioned seemingly being static. Project Targets | Xmake.
I know as facts that
xrepo currently doesn’t have rubberband, so I configured to get it via vcpkg.
I passed the command with -k shared
The teminal eventually tells,
rubberband is only supported on ‘!uwp & !(windows & static) & !xbox’, which does not match x64-windows-static-md. This usually means that there are known build failures, or runtime problems, when building other platforms. To ignore this and attempt to build rubberband anyway, rerun vcpkg with --allow-unsupported.
The way I see the situation, I need to now prioritize getting rubberband onto xrepo to avoid any shenanigans due to getting it through vcpkg maybe not conforming to what’s passed to xmake.
libsigc++/glibmm/cairomm/pangomm. In the code block I shared a few messages earlier, it contains add_requires("pangomm <2.48.0"). This automatically covers installing libsigc++2.12.1, glibmm 2.66.8, cairomm 1.14.15 and pangomm 2.46.4. Only differences than what I got the working Ardour build is the glibmm and pangomm versions. glibmm should be fine, and due to the above error I didn’t get to test pangomm.
Would be trivial to submit 2.42.2 as a buildable version to xrepo though, should I face any errors for the newer pangomm version.
That all looks quite promising. One of the big drawbacks with vcpkg (as far as I could tell anyway…) was that it seemed to have no support for libsigc++ version 2 at all
I think I’ve fixed the rubberband issue in some way (by learning xmake’s equivalent of vcpkg’s ports/conan’s recipes), but there might be some issue causing the dependencies I still get from vcpkg to not be built in the process. I’ll have to investigate. But nonetheless: progress is being made.
Also: I’m curious as to whether it’d be preferable to have a single xmake.lua file, or whether people would not mind having to deal with possibly 2 more xmake.lua files (depending on whether or not 2 more pr’s don’t get merged relating to rubberband and a pango issue).
Just out of interest Stephen, did you ever manage to build pangomm using vcpkg? I’ve found that nothing earlier than the most recent version will build. A few hours ago I managed to figure out how to build libsig++ version 2 which allowed me to build early versions of glibmm and loads of other stuff but pangomm seems to be totally unbuildable.
Nope, furthest I got was glibmm, I remember that very well. I think I was using a 2021 baseline, but still the oldest cairomm was 1.15.x, which is higher than 1.14.x-or-lower, which is ABI compatible.
That being said, it appears that some matters are more complex on xmake, namely the passing of shared/static and release/debug configuration to dependencies of libraries, and the fact that there seems to be no… global(?) integration of pkgconf/pkg-config, and that the .pc files once installed don’t seem easily targetable together.
All that being said, all those problems should be fixable by some lua scripting within an xmake.lua file. So just more effort on my side, but doesn’t mean I need to go back to vcpkg.
(Although, one can wonder: Due to the helperlist getting added to ardour’s source files, I can target versions of glibmm higher than 2.62 that are part of the glibmm-2.4 ABI. That would mean that either approach of vcpkg’s port files or the mix of vcpkg + python scripting that is shared could be simplified due to being able to use the meson build system for glibmm. If you want me to revisit either or both: I can, and I don’t mind covering multiple approaches on my repo on installing the dependencies. But I would still be recommending xmake approach over those, once that is finalized.)
That’s what I’ve found too. I can’t find the quote but Robin summed this up best when he said that for Linux, package managers have been around for decades and they’re very comprehensive. But for Windows it’s the opposite. The Windows package managers come quite close to what’s needed for building Ardour but as things stand, none of them quite comes close enough.
Sorry if this is a dumb-ass idea but whichever package manager Robin uses (pacman?) can it be downloaded for Windows users (say, people who want to build with MinGW or Cygwin?)
If that was possible, maybe a simpler idea would for @EZ4Stephen to come up with some way to generate a Visual Studio solution file with a bunch of VC project files??
Alternatively, maybe @EZ4Stephen could extract the various source files and make them available through a git repo, along with a VS .sln file and all the .vcxproj files?
I just remembered that I’ve a copy of Debian installed within Windows via WSL (Windows Subsystem for Linux) so pacman or whatever should be runnable anyway. Also, Debian here can mount Windows drives so it’s trivial to copy stuff between the two OS’s.
So if pacman could be made to work, @EZ4Stephen could use the Linux package manager instead of faffing about with Windows ones. Then all he’d need to do would be to write a script which copies the source files to Windows and generates a .vcxproj file for each library. That really doesn’t sound difficult.
Not quite. Assuming pacman is the right package manager it’ll expect to build using gcc (and likely some other supported compilers - but MSVC won’t be one of them). But before it can build any library it needs to start by downloading the source files. The important thing is that you’d have the exact same sources that Robin uses so you can build the exact same library versions.
Once you’ve got the right sources you just need to create a VC project file and then the code is immediately buildable with MSVC. The simplest way to generate a VC project file would be to use a basic template with everything pre-configured except for no source files, no pre-processor directives and no library dependencies. Then just copy the template to make the new VC project file, add those missing items and the library would become buildable with MSVC (if that all makes sense!)
So you’re suggesting to be able to download all the same dependency packages’ sources that are used for the official MinGW builds, but then be able to build and install them using a visual studio solution, thus being with the exact same libraries as the current official MinGW builds, but with msvc/clang-cl?
I never thought of that as an option, and I’ll look into it later. But first, it feels more natural that people will seek to build using package managers like vcpkg/xmake. I’ll cover those first, then look into your suggestion. (If I somehow interpreted your idea correctly)
Yes that’s it. I guess we could do with some input from @x42 here. I’m assuming he occasionally needs to patch some source files for certain libraries. So if that’s the case, it might hopefully be possible to download the sources without needing to run the build? If you needed to build everything with MinGW before it became buildable with MSVC that’d be too timewasting
Hmmm… this morning I was looking through my support stack here and I realised that the template idea most likely makes this unworkable
Most of my VS project files here contain pre-build steps, post-build steps and pre-link steps but unfortunately they’re different for different libraries. And in many cases some are needed when building certain libraries but not others, so it ain’t as simple as I first thought
I don’t quite understand: Were you like, making use of MSBuild as a custom build system with custom build instructions for libraries, or were they making use of libraries’ build systems like cmake/meson? I definitely won’t be doing the former.
Sorry Stephen I’ve misunderstood something. A few weeks ago in a different thread you mentioned this:-
I mis-read it. I thought you meant generating .sln / .vcxproj files (which are basically just wrappers around MSBuild). I missed the bit about you still wanting to build via waf.
A lot of concepts are being tangled here. I thought you were referring to building dependencies, not Ardour. Rather than creating further misunderstandings, I suggest we momentarily pause the discussion altogether until I (or someone else out of nowhere) provide 1-3 updated methods of getting the dependencies that clean up the mess from glibmm from earlier. (Ideally, I drop at least 1 within 24 hours.)
I might have to look into writing .pc files for libwebsockets, but apart from that, all dependencies (that aren’t msvc, perl or llvm-nm) (excluding cppunit and lrdf) should be there.
Note: If you do get strawberry perl for windows, make sure to set PATH to include where pkgconf is located (and rename pkgconf to pkg-config. I originally had it automated in the script but I removed it.)
What I did: $env:path = "C:\ADeps3\vcpkg\installed\x64-windows\tools\pkgconf;$env:PATH"
Aside from that, you just run the python script, and once it’s done you add the include and lib folders to --also-include and --also-libdir when building ardour. Cautiously assume building dependencies takes 8GB and 2 hours, I don’t know the actual value.
