MSVC Compiler support - a good idea?

Hi,

As a Programmer myself i was reading some of the comments regarding MSVC Compiler support. So i test wise checked out the source and was able to compile a few dependency libs but by far not all. I saw there is a Mixbus3 Visual Studio Project file and it looked to me there was already some sort of attempt doing it.

I also checked if WAF could be used to target the MSVC Compiler (2022/latest) with it but i was not successfull getting waf to even recognize MSVC. I had a few good experiences sharing code between GCC/CLANG and MSVC, using CMake (even if it’s not my cup of tea) but at least it worked out.

But back to topic.
Is there any bennefit or positive side effect trying/building Ardour with MSVC or is it just a waste of time trying it?

As for my knowledge, the (MSVC) C Compiler isn’t realy developed anymore, bc Microsoft is trying t
o focus on C++ only. So C 89 compliance should be ok, but everything above can be tricky.

Maybe John or some of the more experienced Dev’s can say a few things about the matter.

I though @John_E already kept that support working.

Sorry Chris but that was quite some time ago… I still build Ardour and Mixbus here but the support stack stopped being buildable with MSVC long ago. Most of the libs don’t support MSVC at all any more and even for those that do, their support is now well out of date. For example, the various “mm” libraries (atkmm / gtkmm etc) all need to generate “.def” files (module definition files) but their generated .def’s are only compatible with older versions of MSVC. My gut feeling is that @Dravion only got as far as building the ‘C’ libraries. For C++, gcc isn’t at all compatible with MSVC or Clang (not on Windows anyway…)

Having said that… I’m sure there was a developer here (2 or 3 years ago?) who decided to see if he could build Ardour using MSVC, except built against the most recent versions of each support lib. It did compile and link but IIRC there were lots of runtime issues and he gave up in the end. Sorry, I can’t remember his name but that approach looked promising for a while.

Since then though, another promising solution has emerged in Microsoft’s collaboration with Clang. I’ve been trialling it here and Clang’s built modules are wonderfully compatible with MSVC - e.g. the C++ ones use the same name-mangling scheme as MSVC and the same layout for struct members etc. I can happily intermingle Clang libs and MSVC libs here.

And the support libs have traditionally been the area of contention for budding developers. They’re all keen to jump in with Ardour or Mixbus but they invariably give up once they realise the myriad of support libs they need to build first… :frowning:

So if we do ever figure out a way to build the support stack using waf and Clang, that could possibly offer pre-built ‘dev’ libraries (i.e. with header files). In fact the support libs are so far out of date that if ‘dev’ packages could be released for all 3 platforms, that’d surely be helpful in attracting developers?

Thanks for clarifying @John_E

I was able to test build the following libs with the MSVC 17.8 via VS Native x64 build shell:

libexpat.dll v2.5.0.0, libiconv.dll v1.17, turbojpeg.dll v3.0.1 / jpeg62.dll v3.0.1, liblzma.lib (static)
libpng16.dll, tiff.dll v4.6.0, zlib.dll v1.3.0, curl4

According to MSVC dumpbin, Ardour.exe is dynamically linked to:

dumpbin /NOLOGO /DEPENDENTS Ardour.exe

Dump of file Ardour.exe

libatkmm-1.6-1.dll
libcairo-2.dll
libcairomm-1.0-1.dll
libcurl-4.dll
libfftw3f-3.dll
libfontconfig-1.dll
libgdk-win32-2.0-0.dll
libgdkmm-2.4-1.dll
libglib-2.0-0.dll
libglibmm-2.4-1.dll
libgobject-2.0-0.dll
libgtk-win32-2.0-0.dll
libgtkmm-2.4-1.dll
libintl-8.dll
liblo-7.dll
libpango-1.0-0.dll
libpangocairo-1.0-0.dll
libpangoft2-1.0-0.dll
libpangomm-1.4-1.dll
libsigc-2.0-0.dll
libxml2-2.dll
lilv-0.dll
suil-0.dll
GDI32.dll
KERNEL32.dll
msvcrt.dll
libwinpthread-1.dll
USER32.dll
libgcc_s_seh-1.dll
libstdc++-6.dll
ardour-3.dll
audiographer-0.dll
canvas-0.dll
ardourcp.dll
evoral-0.dll
gtkmm2ext-0.dll
midipp-4.dll
pbd-4.dll
ptformat-0.dll
temporal-0.dll
waveview-0.dll
widgets-0.dll

But there where some list in the Dev Documents with way more Libs and i think the part of the DLL’s i build above are required for GTK2 itself.

But before we go any further. Is this really somewhat useful?
I can do some tests but if nobody needs it, maybe it’s not worth the time even doing it.

Likely no one else is going to maintain it, at least at first (possibly it would attract contributors later if proven useful), so maybe a better question is do you need it? It is really difficult to find motivation to volunteer a lot of effort for something that you do not find useful yourself.

@John_E

Yes, that makes sense.

Tbh, i really don’t need it. It would be some form of fun challenge project, just to see if it’s possible. So really i doubt it’s a valuable contribution.

But maybe it’s worth adding this Question to the Developer Documentation/Faq’s ?

Hi @Dravion - the real goal on Windows would be Clang and waf. Given its compatibility with MSVC, I suppose my mission is to persuade the main developers to start experimenting with Clang as a build tool on Windows. I’ve been involved in Ardour and Mixbus for a very long time and I’ve maybe seen a couple of dozen volunteers wanting to join in on Windows if they could use MSVC. But I can only remember one who wanted to get involved as a MinGW developer. On Windows, it’s just not a popular build tool. Clang would be great for attracting Windows devs, whether as the main compiler or simply an alternative to gcc.

So in that sense, if you could show the main devs that the support stack can be built using waf and Clang, that’d be a huge step forward. Over at Harrison there’s a guy called Todd who once tried building with waf and MSVC but just like you, he found too many problems and gave up in the end. But if you can get your head around waf, waf and Clang should be a lot simpler.

@John_E

I believe in a recent Post of the two Main Dev’s there was some talk about going away from WAF to Meson, but there was not much love especially for CMake and Autotools. With WAF on Windows with MSVC i had very limited success while cmake as a build system which can cater MSVC and GCC and CLANG at the same time from the same source and header’s makes it a lot easier to do source based cross platform compile, without MinGW or MSYS2 installations. But i don’t know a lot about MESON other then building Pidgin3 (IRC and Chat client under Debian Testing successful with it it with the help of the Main Dev Gary Kramlich as he was live on Twitch as responded to some problems with Meson.

However: The Phind Dev A.I responded to the question, if the MESON build system can be used in the same way as CMake (having one source, build the binaries on different platforms) should be possible.

The response was:

Meson is designed to be cross-platform and works with different compilers and environments without requiring changes to the build script itself.

From what i found out, a minimalistic C/C++ Program with MESON on all Ardour Platforms could work like this:

/* Small C/C++ test program /*

#include “my_header.h”

int main(void) {
print_hello();
return 0;
}

/’ Custom header */

#ifndef MY_HEADER_H
#define MY_HEADER_H

void print_hello(void);

#endif // MY_HEADER_H

/* Corresponding source for custom header */
#include <stdio.h>
#include “my_header.h”

void print_hello(void) {
printf(“Hello, World!\n”);
}

// The MESON Build script: meson.build

As far as i know, it is also the favored GTK build system but i am not sure if this covers GTK2 as well.
It sure does GTK3 and GTK4 and as well the Genome GLIB’s,

executable(‘my_program’, ‘main.c’, ‘hello.c’,
include_directories: include_directories(‘.’),
install: true)

Now build the thing with MSVC and MESON - expects meson.build file
meson setup builddir --backend vs2019*
meson compile -C builddir

// creates a Windows PE32+ 64-But x86_64 Bit Executable

// Now the same for GCC and CLANG on NIX
meson setup builddir

meson compile -C builddir*

// created a Linux ELF, MachO x86_64 or ARM64 executable
It looks like CMake works to me and. The ABI is different for any platform but you have
just 1 source, 1 build script but many binaries for different Compilers and operating systems.

Some good points there and I must admit, my experiences with CMake have always been good ones. I’m often confused about the general hostility towards it here. Diff’rent strokes for diff’rent folks I guess.

But I hadn’t heard about the move to Meson and yes, that’d make it a waste of time to be working on waf and Clang. I’ve heard about Meson but don’t know much about it. I’ll do some reading.

Ok, seems to work on Windows with MSVC

and on Linux (Raspberry pi 32-Bit device) it looks like this:

@x42 @paul @BenLoftis - I know Windows development comes up over and over, so sorry to rake it up again - BUT…

Might it be the case that Clang is the link that’s been missing so far? i.e. a compiler that’s compatible with MSVC but with an instruction set that’s modelled on gcc?

I’m wondering if that could be helpful in attracting new developers - what do you guys think?

As usual, we don’t care much… we’re not going to run windows on our builld systems. If someone gets clang working, great. Maybe we’ll use it, maybe we won’t.

There’s zero chance that we will switch to meson. I am not sure what gave anyone that idea.

It came from this disucssion:

Blockquote

Ardour used scons in early days (ardour2), as well.

@x42

We definitely won’t do that. I hate cmake with passion, but that is a different story.
If Ardour were to use a new build system, I would be something sane, like meson.

So maybe Ardour will see an influx of new contributors after the next banking collapse?
Pretty sure most of those guys develop for Linux, so might not help regarding the current discussion.

Chris - my thinking was that there’s a regular stream of programmers interested in getting on board, though in most cases they seem to want to start off with MSVC. But until now, there’d been no easy way to transfer MSVC skills to either gcc or to the non-Windows platforms.

But I’ve a feeling Clang could offer a route here. So if people could get on board by starting off with MSVC and Clang, at least some of them would likely pick up skills that’d be transferable to gcc and to the other platforms.

Whether that’s useful or not, I don’t know.

@John_E

Regarding CLANG, i checked it. So far the MSVC and MS-CLANG, FreeBSD CLANG and MacOS-CLANG version all working together in concert with the same code and the same meson.build file, it’s pretty much as good as cmake imho.

Example code: https://github.com/Dravion/meson_test

Screenshots for FreeBSD and MacOS:


and

@Dravion - I’m also of the view that compatibility between compilers would be a step forward (and a big help for attracting new programmers). But the message I’m picking up here is that any new build system (or new programmers) would only be of interest if they don’t introduce bottlenecks for Ardour. So whereas Meson might give great results for a small build, so did the previous build system (scons).

The view here is that waf and gcc have shown themselves to still be fast - even when dealing with a large and complex project. And that’s very much the acid test.

Yes. But i didn’t pickup meson as build system just for fun. It was my impression that WAF has maybe some sort of drawbacks and there maybe is a desire to implement a new system. As you may know, i personal favored GNU Autotools or CMake. Scons would be fine with me as well.

However: Now i checked MESON myself and it looks like a awesome build tool, which can help to share code between Compilers and between Operating systems as easy as possible. It looks mature and reliable so i was productive testing and checking it out. Maybe it is useful for me in some other projects, i will find out^^

As far as my understanding goes, Paul made it clear that there will be no replacement for WAF (please correct me if i am wrong). I checked WAF as well, but it looks a bit more complex to get it working cross compilers like Cmake or WAF, but maybe i am wrong and i need to learn more about WAF.

With the help of Paul info’s in another Discussion, i was able to build Ardour 8.2 from source with
WAF on Ubuntu Studio LTS. But Unfortently, this was the only distro which worked out. Even the MSYS2 build wasn’t successful in my case.

Yes, WAF is the way to go in terms of Ardour. If i have time i will check WAF next for MSVC, maybe there is a way to make it work. Would be a nice challenge convincing it to do so^^

PS: Yeah, the acid test. A small demo setup to see a build system working is oc not the same as
to build all Ardour dependencies and the program itself. However: I will check WAF for MSVC and maybe it works out, we will see.

Thanks for your ideas and help and have a awesome day.

Here on Windows, Clang produces perfectly good code (and highly compatible code) but I can’t deny it’s a pretty slow compiler compared to MSVC (very slow in fact !!)

So for me, the goal would be to restrict it to the support stack, rather than Ardour itself. Presumably the support stack doesn’t need to get built too often? And it’s just my 2 cents but my gut feeling is that a downloadable / easily available / highly compatible support stack could be quite a help in attracting new programmers.

I suspect the main devs are worried it’ll attract budding, enthusiastic (but mostly inexperienced) programmers… :frowning:

Ok, just a little update - now regarding WAF.

It is possible to use it with MSVC, it’s even possible to connect to a Windows box via SSH and let it compile remote on a Win box. Tbh, it’s way less complex then MESON or CMake or Autotools, i was really surprised. To clarify MSVC direct compile via Visual Studio Command prompt and remote Compile just via SSH can be done.


and Solaris11 on AMD64 remotely also via SSH

So far, there might be limits i am not aware of, but WAF is impressed bc it’s a clear cut design and
does the Job. Any way, i learned a lot and maybe the findings are of value for some peeoples

Demo code:
https://github.com/Dravion/waf_tests