"libs/{platform}" folder in custom modules should be name-independent

1

Hello,
I came across a problem when including *.lib files in my custom module :
The project I’m testing it on ( Chataigne | Chataigne ) has 3 VS2019 exporters, 1 for local testing using global juce path, and 2 others for CI (one for Win7 and one for Win8+).

I found out that while the documentation say

libs/VisualStudio{year}/{arch}/{run-time}, where {year} is the four digit year of the Visual Studio release

It’s not specifying that what is actually checked is the build folder name of the exporter. My 2 CI exporters are called VisualStudio2019_CI and VisualStudio_Win7CI , so right now I should have 3 folders in my module called by those names in order to have the lib search path included.

While it may be interesting to separate exporters of the same platforms in the include, juce modules are supposed to be project independent, thus working for any project they are included in, and this breaks the compatibility with any VS2019 exporter that is not named “VisualStudio2019”.

I’ve not pushed a PR because I still have pushed PRs from years ago that have not been even looked at, and my forked JUCE repo has now too many modified code to push a clean PR.

Here is the line of code that should change imho :

juce_Modules.cpp, line 71 :
libDirPlatform = exporter.getTargetFolder().getFileName();
to
libDirPlatform = exporter.getCurrentPlatformExporterTypeInfo().targetFolder;

Cheers

2

EDIT :
This is still not a good solution as the getCurrentPlatformExporterTypeInfo() is not exporter dependant but is compilation dependant, so all project exporters will get the same typeInfos.
I’m not sure why the structure is made this way but there seem to be absolutely no way to retrieve the typeinfo related to an exporter… ??
I ended up adding a method getTargetPlatformName that is [re]implemented in all exporters, mostly linking to their respective static method getTargetFolderName() (or with a check when multiple possibilities like mac/ios)

Is there any cleaner way to do this ?

3

This does look like a Projucer bug, and the solution that you mentioned (adding a virtual getExporterIdentifier function) seems like a reasonable solution as a way to get the current exporter’s targetFolder name.

I’ve merged that change here:

Please let me know if you run into any issues with this change.

4

Hello, sorry didn’t get notification for the reply.
I think this is the right way, just tried it it seems all good :slight_smile: