JUCE should allow to build porjects for any target with a makefile.
The issue: I want to create an audio plugin for Windows but am forced to use VS Community, which is not only large but also 90% composed of features I will never use.
I would feel more comfortable if I had the option to develop for all platforms with a makefile, so I can use VS Code instead.
I’ve not done this but I believe you can still use VS Code if you just configure the build command to use MSBuild.exe. You can get this by installing the Windows Build Tools component.
Not exactly sure what the best debugging approach is with VS Code though.
I do agree though, more straightforward VS Code support would be great.
1 Like
Thank you for reminding me of the Windows Build Tools! I still feel like this should be mentioned in the documentation at least. Also this does not allow you to perform cross-platform compilations, as far as I am aware of.
I used to build all my JUCE based Windows plugins with Mingw/MSYS. I had to write Windows specific makefiles, but they worked just fine.
I’ve cross-compiled Windows plug-ins from Linux, but i don’t recommend it. You open yourself up to lots of subtle differences in behaviour and (a few years ago) I had to put some really nasty workarounds in the plug-in SDKs. Maybe things have improved now, but it was bad enough that I decided running a whole additional operating system was worth it.
That is exactly why I would love JUCE to support cross-compiling officially.
Cross compilation produces problems beyond what JUCE can handle.
I had to put really intrusive changes into the plug-in SDKs and monkey about in the headers included in MinGW too. You need to worry about things like different layouts of virtual tables when passing even pure virtual classes across plug-in boundaries (when the host application has probably been compiled using MSVC, but it might not have been). You need to port a whole toolchain and reverse engineer some small Apple utilities if you want to target macOS, and using advanced features like notarization are probably beyond reach.
If you’re willing and capable of going through all of that pain then producing a Makefile will be a straightforward task. It’s not something we want to encourage.
4 Likes
I’ve never really understood the appeal of cross-compiling. Even if you can generate binaries that run on other OSes how do you test them? Or debug them?
Surely at some point you need to run them on the target OS yourself before releasing them?
Wouldn’t a more sensible approach be to get some CI set-up to build the different platforms?
5 Likes
In embedded systems it is definitely the only way of dealing with it - it’s what I have to do on a daily basis. It’s painful, it sucks, but the device doesn’t have the space or capabilities to build anything.
On the other hand, in the context of building JUCE apps/libs, it definitely makes sense to not bother cross-compiling at all.
Yeah, obviously if there are hardware constraints then this makes sense and is sometimes the only way (like embedded or even Raspberry Pi) but the OP did state they were building “an audio plugin for Windows”.
You might want to have a look at FRUT (I’m the author), which allows building JUCE projects using CMake. I’m not using VS Code, but I’m pretty sure there is some integration with CMake. In the worst case, CMake can generate several kinds of Makefiles (Borland, NMake, MSYS, MinGW, and Unix) on Windows.