VST Include Path on Build System

General JUCE discussion
1

Hi JUCE team, I’m having a really hard time getting the PJ to create working IDE files since the addition of the VST SDK to the JUCE source files.
The include path that the PJ adds to find the VST SDK seems to be a little bit magic, it’s not really documented and there are so many fallbacks etc. that it’s very hard to be sure of the final location it will use.

Further to this, if I have other jobs on my build server that do things like generate projects from PIPs, or even if I open the PJ, the global paths often need to get set. These can then point to directories that immediately get deleted when the job finishes or even worse, if two jobs are being executed at the same time they can interfere. (E.g. if Job A sets the global path then Job B resaves its projects, Job B ends up point to JUCE from Job A which can an incorrect version or not there at all!).

I understand the use cases for global paths but for consistency across team members and build machines etc. can we have a way to simply turn them off? Perhaps either

  1. A setting in a PJ to “ignore global settings and always use defaults”
    or
  2. Add a setting to the PJ to the VST2 and VST3 SDKs which defaults to the one contained in JUCE?

Or are we supposed to implement (2) ourselves with the header search paths setting in the PJ? If so, I don’t want the PJ to add any VST SDK paths itself as that could interfere with ours?

Just some thoughts for those of us heavily reliant on CI :wink:

There’s also another use case that currently doesn’t work, generating projects from PIPs with non-JUCE modules located in multiple directories. Ideally, you should be able to send a list of dirs to look in for user modules when using the --create-from-pip flag…

2 Likes
2

This commit should fix an issue with the Projucer determining whether to use the embedded VST3 SDK or not. Basically, older projects that had previously set this path using the old per-exporter field (which has been removed since the global paths options were added) were using this invisible path SDK instead of the embedded one, even though the “Custom VST3 SDK” field in the global paths box was empty. So now the logic is quite clear - empty global path = use embedded SDK, otherwise use the path specified.

I’m not quite sure what you mean here, what would the defaults be? If you set your modules to not use the global path then they will use the explicit paths that you have set (which might be the best way to do things if you have multiple versions of JUCE).

3

Thanks, yeah I noticed that invisible path was getting used so I had to manually chop it out of my .jucer files.

This isn’t quite true though, because on a build system, other jobs may have set, or could be racing on this setting…

What I mean is if there was a setting to never look in the global settings, basically act as if they are always empty. This way I wouldn’t have to worry about other jobs setting the global settings and could be sure that the values in the project are being used.

Does that make things a bit clearer?