turning off the “treat warnings as errors” is just to get the AAX sdk to compile without dealing with all those warnings.
Yep, your absolutely right! The AAX SDK must be compiled with “warnings as errors” turned off, otherwise it is a mess!
As an update on this, I tried again to upgrade to VS2017 and experienced similar issues to those described here: https://social.msdn.microsoft.com/Forums/vstudio/en-US/5150eeec-4427-440f-ab19-aecb26113d31/updated-to-vs-2015-and-now-get-unresolved-external-errors?forum=vcgeneral
Solving ended up being as simple as adding legacy_stdio_definitions.lib to the External Libraries to Link in the Projucer. All seems to be working well, I’ve been using VS2017 for the project now for a few weeks with no obvious new problems.
1 Like
Hey fellas,
Probably too late to be relevant, but I’ll chime in anyway:
Was successfully able to build our plugin as VST3 with JUCE 5.4.1 and VS2013.
- Had to manually set JUCE_PLUGINHOST_VST to 0 in the jucer file. (couldn’t find the option in the actual Projucer… does it exist?).
- Had to comment out all ‘constexpr’ in the VST3 SDK (modules\juce_audio_processors\format_types\VST3_SDK\pluginterfaces\base\ipluginbase.h) since it’s outside the scope of JUCE_CONSTEXPR.
We are still on VS2013 due to a ton of older software products which we are still updating, but for our plugin we are going to switch to VS2017 soon (especially since most of you seem to have been able to build AAX using VS2017).
modules → juce_audio_processors
Ah of course! Thanks Tom.
3 Likes
Nice! How exciting!
The most limiting factor for us now in terms of C++ language features we can adopt is supporting GCC < 5.0, which is more problematic to update as some embedded toolchains move very slowly.
Yeah, there are various issues with pre-5.0 GCC. Most can be worked around though via backporting, I believe? What kind of other features would you really be after to make 5.0 a baseline?
constexpr is the most obvious one and I think this might also let us move to C++14 by default.