I’m using environment variables as paths for JUCE project dependencies. This helps a ton for CI purposes, especially when using self-hosted agents which are also development machines.
The problem is, currently Projucer forces you to provide valid global paths and these global paths can conflict with the CI environment variables, causing the wrong dependency to be used. This is because the global paths are always appended to the compiler/linker paths.
Either the ability to specify environment variables instead of paths, or the ability to disable global paths entirely, would eliminate this issue.
I am having a similar issue with global paths. I was looking to get support for globals to be relative paths to the project. I am using CI so the absolute path I have on my local machine does not exist on the CI build machine.
Anyone have thoughts on how to work around this inside projucer? Can we get support added to projucer for this?
I am doing find/replace on my VS proj files to manually work around this
You can specify relative paths and environment variables for each project exporter (under the compiler/linker settings). These vary slightly per-exporter, but it’s pretty straightforward. These will get passed along to the compiler/linker command-line as-is. Problem is the global paths also get included, and they can take priority if the build machine happens to also be a development machine where those paths exist. Then you end up with a Frankenstein build using the wrong module version(s).
I never actually found a solution for my problem, I just sort of deal with it on development machines. For production builds, I don’t let a development machine be involved in the build process at all other than running the unit tests on the production builds. It’s always a clean agent which avoids issues like this.
