Fix include paths inconsistency in case vst2 sdk path is set

[danra]

trafficstars

All include paths set by JUCE are regular, non-system ones, -except- if a vst2 sdk path is set, in which case both the vst2 sdk path and the vst3 sdk path (custom or not) become system includes. This commit removes the exceptional behavior.

The sdks include paths order (VST3 preceding VST2) is kept.

Note: The approach in the commit assumes noone would need a juce_vst2_headers target in addition to the juce_vst3_headers one. If that's not the case, it's easy to modify the commit to instead define such an additional target.

[reuk]

What CMake version, CMake generator, and compiler version produces the behaviour you're seeing?

[reuk]

Never mind, I can repro with Visual Studio. I think the fix is to add "SYSTEM FALSE" or "IMPORTED_NO_SYSTEM TRUE" to the plugin sdk targets' properties.

[danra]

@reuk Why? I mean, that would work, but my method removes some code literally commented with "This is a bit of a hack", replacing it with a cleaner alternative

[reuk]

We've merged a fix for this issue here: https://github.com/juce-framework/JUCE/commit/047f7aaad2898609cda1dfd5c6c184aef2623bbf

The merged fix should resolve the issue for all of the external SDKs, not just VST2 and VST3.