I want to be part of it

We won’t switch. It’s just another compiler option. Ardour does and should build with most C++ compilers. Clang is already used for the complete build-stack and Arodur itself on MacOS, as well as for static analysis on Linux. For Ardour itself it should be possible to directly generate a VC project using ardour’s waf build system again.

From my perspective it looks like build systems of the build-dependencies are the problem.

In particular autotools which is used by most libs doesn’t directly work and needs msys on Windows. Mid/long term meson will hopefully sort that out. Many of the libs that Ardour depends on have already migrated to meson. That way only 2 or 3 projects (like gtk2) will need to be ported manually.

Is there an established container/image, chroot environment that could provide a build-system (pre-compiled libs, headers, SDKs)? Something we could prepare (once), and provide to get windows devs started.

+1

1 Like

I remember Todd started work on this many years ago. I could be wrong but for some reason I thought it had gotten abandoned?

Not for VC++ - one of the problems (historically) was that you couldn’t link modules written in a particular VC++ version with modules written in some previous version. It’d work okay for ordinary ‘C’ but not for C++ (because each version had a different name mangling scheme).

However… I just compiled libpbd with VS2019 to see if that’s still the case and I was surprised to find that it isn’t. I didn’t manage to link successfully but there were only 2 x unresolved externals. So (unless Microsoft is fooling me…) it looks like they’ve maybe done some work to consolidate all this stuff. And if that’s the case it might be feasible now to create a container with pre-compiled libs and header files. It might be worth asking some of the glib/gtk devs as they’re likely to know what the current situation is.

1 Like

We have recently (January 2020) updated waf to version 2.0.19 (from 1.6.11) due allow building with both python 2 and 3. – The version that we use now, apparently works for fine to create VC projects for LV2kit. It may need some work to tweak Ardour’s wscripts, but it’s probably easier than it was 8 years ago

Anyway for Ardour itself, it’s probably not a big deal to maintain a separate VS project.

That’d be great!

1 Like

Hi Robin and John!

Nice conversation, by the way.

I know the strains and the in house position on this already. But maybe, a group force could be gathered to get a native Windows compilation ready. Although I would be the least useful man, I’d like to join in.

Hopefully John gets excited about it.

By the way #1: just for the kicks, I tried to build the MixBus3 solution in the source, with VS2017. I thought I would get more errors. I wouldn’t mind posting the error monitor for you guys.

By the way #2: I found an inconsistency in the Mackie MCU pro interface behaviour (I own a MCU Pro + MCU XT). I might try to fix that myself, somehow (once I manage to compile the thing)

If you’re building from my solution file you’d need to be building against my specific versions of the support libraries:- https://github.com/johne53?tab=repositories

The first one to get built is MB3Proxy-libintl - maybe try building that one and see how you get on. The others all have a page of build instructions (which that one doesn’t have for some reason) but IIRC it’s quite a simple build.

[Edit…] BTW… it’ll probably go easier if you use the same directory layout as me:-

your drive:\+GTK-SOURCES\gnu-windows\src\MB3Proxy-libintl

1 Like

LordAdef - I’ve pushed some small changes to Ardour git which might help you compile with VS2017. This is only a small test so I’ve only updated the pbd branch. You should start by building the target that’s called Release 32 with Debugging Capability. Of course, it might not compile if you’ve installed someone else’s version of the support libs so in the longer term (assuming you want something that’ll eventually link and run) you’d need to build my support libraries like I mentioned yesterday.

gcc and waf would almost certainly be a simpler way to start though… :slightly_smiling_face:

1 Like

thanks John! I’ll try that.

please allow me some noob questions:

Cygwin or MinGW (it’s all new to me)?

Lastly, is your Mixbus3 solution equivalent to Ardour 5?

My projects can work with the current version of Ardour but they don’t use the current version of Visual C++. Here’s a bit of background information…

Many years ago, I created my projects (along with my customised dependency libs) to build an early version of Mixbus with a much earlier version of Visual C++. But VC++ isn’t cross-platform - so eventually it got superceded in favour of gcc and waf. VC++ no longer forms part of Ardour’s development strategy (and in fact I’m not part of the core development team any more - I’m really just a peripheral contributer).

As for Cygwin and minGW - I don’t think either of them gets used in Ardour development. I’ve a feeling that the current Windows stuff gets built in Linux using some kind of cross-compilation system. It might involve a related technology (such as ‘Wine’) but I don’t know for certain. Robin and Paul will have more info about this.

If you’re keen to get involved quickly with Ardour, Visual C++ really isn’t a simple route. You should consider cross-compiling with gcc and waf because that’s how the current development works. Later (once you’re more experienced with Ardour and C++) that’d be a much better time to experiment with VC++ and maybe bring my old projects up to date.

1 Like

nice John! And thanks for tour patience.
I will do my homework and see what I can achieve.
Cheers

Yes. mingw is used to cross-compile Ardour. The compiler runs directly on GNU/Linux, and produces windows binaries. The NSIS installer also has a Linux version that can create windows installers.

Wine would be needed to run Windows applications on Linux. It is not required to build and package Ardour, although we have used it to run unit-tests.

The nice part of this is that it works reliably, can be scripted for CI/CD and provide nightly builds.

It’s not impossible to build Ardour on windows using a similar toolchain: https://guysherman.com/2015/08/16/building-ardour-on-windows-with-msys2/ but for the case at hand that’s likely not helpful.

1 Like

FWIW these are the lines causing the unresolved externals (in StandardTimer::connect() and BlinkTimer::Connect() respectively) -

return m_signal.connect(slot); - and...
return m_blink_signal.connect(slot);

I don’t know if it’s because ‘slot’ in each case is const (haven’t had time to investigate too deeply). But linking VS2019 code to C++ libs from a previous version does at least seem ‘do-able’ now… :raising_hand_man:

1 Like

@John_E
Hi John!

your drive:+GTK-SOURCES\gnu-windows\src\MB3Proxy-libintl

The first one to get built is MB3Proxy-libintl - maybe try building that one and see how you get on.

On this (VS 2017, on Win 10):

issue 1: VS complaint there were no “intl.props” file. There was a “intl.props.in”, so I made a copy of the 2 “props.in” in there and removed the “.in”. Seemed to work

Here is where I am:

1>------ Build started: Project: intl, Configuration: Debug Win32 ------
1>cl : Command line warning D9035: option ‘Gm’ has been deprecated and will be removed in a future release
1>libintl.c
1>c:+gtk-sources\gnu-windows\src\mb3proxy-libintl\libintl.c : fatal error C1083: Cannot open include file: ‘@TargetSxSFolder@\targetsxs.h’: No such file or directory
1>Done building project “intl.vcxproj” – FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

ps: I just realized you have some extra files at your Github. Going to search there

Oops - there’s a few preliminary stages I forgot about:-

Before doing anything else you need to edit the file called local-paths.lib which you’ll find in the top level folder. IIRC you just need to change F: to your own install drive - so if you installed my code on D: - change F: to D:

Now open a DOS Command Prompt and navigate to the folder where you installed my code:-

and now run the following command (which requires you to have perl installed)-

Then (like I mentioned earlier) be sure to build the target called Release 32 with Debugging Capability before attempting the others. You’ll also need to have python installed for some of the later stages.

There’ll probably be quite a few drawbacks like this at first :grinning:

1 Like

Ok!!

Python on my computer… argh hahaha

The next one in the sequence is MB3Sigc-2 which comes with a page of instructions (so hopefully that’ll make things a bit easier!!) It looks like you also need to install something called M4 although I can’t quite remember what it is (some kind of macro processer maybe??)

1 Like

Hi,
win32-fixup.pl -buildall returns me to following error:

Can’t locate local-paths.lib in @INC (@INC contains: C:/Strawberry/perl/site/lib C:/Strawberry/perl/vendor/lib C:/Strawberry/perl/lib) at C:+GTK-SOURCES\gnu-windows\src\MB3Proxy-libintl\win32-fixup.pl line 4.

local-path.lib is there, and all drivers were changed to c:

Are you running it from a Command Prompt (i.e. not just double-clicking it in Explorer?) Your Command Prompt would need to be here:-

C:\+GTK-SOURCES\gnu-windows\src\MB3Proxy-libintl

Yes, I cd to the location and ran it from there

I’m baffled then… on my system Perl seems to behave the same as DOS - i.e. when searching for a file it starts by looking in the current directory before trying any search paths. For some reason it must be different for you but I can’t think why…

Or maybe I added my MB3Proxy-libintl path to Perl’s @INC path somehow…

[Edit…] No - I just printed out my @INC path and it’s the same as yours :-

C:/strawberry/perl/site/lib C:/strawberry/perl/vendor/lib C:/strawberry/perl/lib

Try adding your edited copy of local-paths.lib (i.e. C:/strawberry/perl/lib/local-paths.lib) - although I haven’t needed to do that here…

Perl didn’t complain.

failed build:

1>cl : Command line warning D9035: option ‘Gm’ has been deprecated and will be removed in a future release
1>libintl.c
1>c:+gtk-sources\gnu-windows\include\ardourext\sys\targetsxs.h(76): fatal error C1083: Cannot open include file: ‘gtkmmconfig.h’: No such file or directory
1>Done building project “intl.vcxproj” – FAILED.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

Btw, Python and M4 already installed!