Issue when using new VS2022 exporter. project using global module paths when it is configured with specific paths

I think there is a bug in the new VS2022 exporter in Projucer. We just updated to (almost) latest JUCE on develop (84cd6152befdc9fdd16ed294bcfb889a2379879e) and I added the new VS2022 exporter, but the module paths are coming our incorrect. They are the global paths, even though the project is setup to use specific paths. Generating the VS2019 project has the correct paths. Of course I noticed it first when I tried to build the VS2022 project, and then verified it by looking at the include paths in the projects themselves.

I have a hunch that the issue is not with the VS2022 exporter itself, but with adding an (any?) exporter. Could you try adding a second VS2019 exporter and see whether that one has the correct paths or not?

I will try that. I have debugged it down to the variable extraSearchPaths containing the wrong data when it is used at export time.

You are correct. Generating a 2nd 2019 project also gets it wrong.

I noticed that if you add a new exporter, regardless of which, the paths default to that of the global ones no matter what. You’re then stuck updating each module’s path, typically by copying from an existing one, into the text box.

This is a really old behaviour in PJ - since the Introjucer days, iirc.

Obviously this is quite annoying when you have modules from different locations because there’s only one option to try to fix this: “Set paths for all modules”. Ideally, I’d prefer a button that allows selected modules to copy paths from a source - not sure exactly how the UX should be there, but there must be an easier way.

My workaround was to just copy an existing exporter’s XML - eg: VS2019 - and rename anything VS2019 in that selection to VS2022.

I don’t think this is a bug in the Projucer. What is happening is that when you add a new exporter the explicit module paths for the new exporter will initially be empty and the “fallback” value is the global modules path. I’m not sure it makes sense for new exporters to copy the explicit path of the other exporters in the project since there could be multiple paths as well as paths for other platforms that may not exist on the running machine - how would it decide which one to copy over? As @jrlanglois said, you’ll need to manually add the explicit paths for the new exporter or edit the XML directly.

I was just pondering about this. In the case that the module has an exporter added, the Projucer could check all of the existing paths the module points to: if they’re all the same, set this path to the new exporter. Otherwise, carry on as usual.

That would be fairly intuitive to me.

Fair enough. Maybe the code doesn’t support it, but since the two exporters are for the same platform, one could surmise that the module paths would be the same. or, an option to choose when creating the exporter. Or, since none of the others are set to global, then at least it should honor that as a starting point. and yes, assuming the paths are the same for all platforms, because that is more likely than people have different paths for each platform.

I think it’s more confusing than the current behaviour, which is at least consistent although not “ideal”.

Hmm… do you think it’s possible you find it less confusing because you are used to it? This is not a tool we spend much time in, so recalling oddities is more difficult. At the minimum, it seems alerting us to the need to visit those paths when adding a new exporter, would be great. Neither choice makes sense because the software can’t know. But, software is all about automation. So, automating a process that will likely need attention seems advantageous. I am up and running, but now I will have to do this process on a handful of other projects.

1 Like

@ed95 can you explain what ProjectExporter::createDefaultModulePaths is attempting to do then? The following code really looks like Projucer is trying to set module paths on the new exporter from another exporter:

Projucer actually had the behavior that @cpr2323 is expecting until JUCE 5.3.2 (inclusive). That behavior was changed/broken in

1 Like

Thanks @mcmartin! Apologies for the delay in replying to this but there were some other changes that were required before I could get around to the original issue. I’ve pushed a fix to develop here: