Edit: I ran the following to look for all mentions of #include <glibmm/threads.h> : (gci -rec -file|sls '#include <glibmm/threads\.h>' -ca).Path|Resolve-Path -Relative|Select -Unique
I got 86 files’ paths listed. Would be neat if someone (or some people) came up with working patches to all 86, to make it work with glibmm-2.68, but I know I’m asking for a lot, and I’ll likely end up working on them one by one till I can edit them all quickly with much fewer commands (like how the above command ‘fixed’ 15 files).
[Initially 87 since I made patches for signals.h, which is mentioned in the original post]
Stephen - I’m not sure if you’re already doing this but each time you successfully build a library in the Support Stack, you need to copy its header files (the public ones, at least) giving each of them an entry in a common #include folder.
I think I’m doing that, but don’t know if I’m doing it right.
Am I getting ahead of myself by trying to deal with all mentions #include <glibmm/threads.h>?
Even in my pursuit of removing them to deal with the fatal error C1083: Cannot open include file: 'glibmm/threads.h': No such file or directory
I’m uncertain on how to go about it. Whether to go file by file, or groups of files at a time? Or some other approach? Could I create a file a new file in libs/glibmm/threads.h (creating a new folder in the process as well) and make it have everything needed to work?
threads.h will be located in glibmm/glib/glibmm (along with the other glibmm header files you’ll need). What I’m saying is that you should copy the header files from that (last) glibmm folder to a dedicated include folder, along with with similar ones for your other projects.
To give another example, the header files for pangomm will be in pangomm/pango/pangomm. The location varies between different projects - and some projects require you to copy header files from multiple folders - but ultimately, you need a similar layout to my screenshot in post #5
Alternatively (I guess?) there was maybe some different mechanism in use when you built with MinGW and whatever that mechanism is, it’ll need to get copied so that it still works when building with MSVC
Maybe Robin could help with this? Does MinGW have some way of assuming or figuring out where header files are, but without the user needing to specify their #include location? MSVC has it’s own set of default folders which get searched automatically - but it doesn’t make any assumptions about where the user’s headers or 3rd party headers might be located…
I’ve made progress to ~20/1838.
Files I edited after the configure step, to make progress in the build:
signals.h
event_loop.h
stack_allocator.h
windows_special_dirs.cc
windows_special_dirs.h
undo.h
id.h
stateful.h
undo.cc
timer.h
timer.cc
controllable.h
stateful.cc
Yet to run git diff on everything but the first 5, and save the outputs. Or share them. The first 5’s are in the main post, at the end.
(Also, the Boost_No_Auto_PTR warning is a little annoying now)
Okay, something’s wrong here… I needed to edit ‘pbd/pbd/string_convert.h’ here (to comment out the lines saying typename T::TO_STRING_TEMPLATE_NOT_DEFINED_FOR_THIS_TYPE invalid_type; because MSVC doesn’t understand it) but I don’t need to edit those others. However, I’ve a lot of extra #defines here (in addition to libpbd’s already defined ones…)
These extra ones are definitely needed:-
UINTSDEFINED=1
_SECURE_SCL=0
PLATFORM_WINDOWS
COMPILER_MSVC
BUILDING_PBD
BUILDING_GETOPT
LIBPBD_DLL_EXPORTS
INCLUDE_ARDOUR_MISCELLANEOUS=1;
WIN32
_WIN32
_WIN64
NDEBUG
These ones might not be needed any more:-
NOMINMAX
NO_POSIX_MEMALIGN
ARCH_X86
USE_XMMINTRIN
LIBC_DISABLE_DEPRECATED
HAVE_STRUCT_TIMESPEC=1
WINDOWS_KEY=“Mod4><Super”;=1
HAVE_JACK_SESSION=1
HAVE_JACK_VIDEO_SUPPORT=1
HAVE_X11=0
And I’ve a lot of #defines relating to libboost but I suspect these are the only ones actually needed;-
BOOST_SYSTEM_NO_DEPRECATED
HAVE_BOOST_SCOPED_PTR_HPP=1
HAVE_BOOST_PTR_CONTAINER_PTR_LIST_HPP=1
HAVE_BOOST_WEAK_PTR_HPP=1
Try adding some at your end and see if you then have more success building libpbd (just start off with the ones that are definitely needed).
[Edit…] BTW you might be able to lose those BOOST warnings by specifying this on your command line:-
Amen! I’m astonished and gratified that folks are doing the ugly work to move this effort forward.
I’ve done a bunch of painful stuff to make cross-platform C/C++ builds work for F/LOSS software over the years, but that stuff is nothing compared to the effort @EZ4Stephen and @John_E are putting in here.
debug.cc has #include <boost/tokenizer.hpp> and gives the following error:
C:\dev\ardour\libs\pbd\debug.cc(30): fatal error C1083: Cannot open include file: ‘boost/tokenizer.hpp’: No such file or directory
I’ll replace that with #include <sstream> and change some more lines in debug.cc to use that.
Also, @x42 regarding alleged performance issues with std::mutex (or however its spelt), did you try replicating it yesterday? When did you last test for that?
@EZ4Stephen - there are one or two exceptions but for the most part, boost is a library implemented as header files so it needs to be contained underneath your top level include folder
Just to be clear, It appears that python waf compiles 8 things at a time for me, usually. So even if this one isn’t fixed, I could theoretically go after everything else (until I get a similar error for 8 files in total or so).
crossthreads.cc wasn’t the last one to show up, but I figured dealing with that file (and .h and .win.cc) are going to take a lot of time, and it’s probably easier to deal with other files while asking for help with these. so it has ended up like this.
Also, base_ui.cc needs one of the crossthreads files… I assume the .h one. Until I fix that, these two will keep taking 2/8 of the compile slots
(Also, I have a theory that the files in libs/pbd were compiled Z to A. And the image shows it being likewise for libs/temporal.)
Edit: Dealt with crossthread, but base_ui.cc is still with errors. If anyone wants the contents of the edited crossthread.cc, crossthread.win.cc or crossthread.h, let me know. I’ll probably end up sharing it later anyways, but I’ll be focusing on other things instead.
@EZ4Stephen - didn’t you once build successfully using MinGW? So how did you get all the support libs? Did MingGW build them for you or did it just supply them all pre-built?
Most support libs were supplied from MinGW, but I had to build portaudio (with ASIO) and FFTW with single precision. I still did a few changes (referring to the MinGW build) to get past a few errors:
sed -i '31i\#if !GLIB_CHECK_VERSION(2,32,0)' libs/pbd/pbd.cc
sed -i '33a\#endif' libs/pbd/pbd.cc
sed -i '92i\#if !GLIB_CHECK_VERSION(2,32,0)' libs/pbd/pbd.cc
sed -i '96a\#endif' libs/pbd/pbd.cc
sed -i "s/obj.uselib += \['LILV'\]/obj.uselib += ['LILV', 'SERD', 'SORD', 'SRATOM']/" libs/ardour/wscript
sed -i "/obj.uselib/a\ obj.stlib = ['portaudio']\n obj.lib = ['ole32', 'setupapi', 'uuid', 'winmm', 'ksuser', 'jack64']" libs/backends/portaudio/wscript
sed -i '264i#if !GLIB_CHECK_VERSION(2,32,0)' gtk2_ardour/main.cc
sed -i '267a#endif' gtk2_ardour/main.cc
Not to mention the configure options used are different. For MinGW, I did
Apologies Stephen - it looks like your MinGW libs must’ve come pre-built, which brings me back to my conclusion from your previous thread:-
Stephen’s made a fantastic effort here but it simply proves what I suspected all along - i.e. the libraries in vcpkg are too modern to be compatible with Ardour.
The problem of course is that Robin and Paul are very busy with their normal work but if they ever hope to attract programmers for the non-Linux platforms, they’ll (somehow) need to start providing pre-built support stacks.
[Edit…] Stephen, if you want to continue trying your build of libpbd I could let you have my header files for glib and glibmm (which you’d need to use instead of your current ones). It won’t link with just the header files of course - but at least it’d tell us if things would be simpler if you did have a pre-built support stack.
Trying python waf -j1 after doing distclean and configure again didn’t solve the issue with base_ui.h. I ended up doing git checkout for base_ui.h and .cc and also got boost-multiprecision with vcpkg install boost-multiprecision.
I’ve then made a few changes so it works with glibmm-2.68.
Apparently it’s a Windows macro pollution issue causing this:
