FRUT compiles JUCE code again and again for multiple projects

[timuraudio]

Is there any way we can avoid that? Currently, the best approach we could find is to manually compile JUCE into a static library and then link that.

[cor3ntin]

We managed to build a Static Library using FRUT an it actually works pretty well. One issue though. On mac the framework are linked privately which causes some link error down the road.

https://github.com/McMartin/FRUT/blob/cb781034163dfc2cd81de0d2746d7a4dcc3369be/cmake/Reprojucer.cmake#L4764-L4789

It would be very helpful for us if that could be changed. For now, we will link manually

[McMartin]

@timuraudio Thanks a lot for using FRUT and for opening this issue! Building a static library might indeed be the best approach for reducing the number of compiler invocations. I'll investigate how several projects can leverage the output of a shared "Static Library" project. It will be rather a hack, but it might be possible.

@cor3ntin Linking against the macOS frameworks publicly would not solve the whole problem. Projects that link against the Static Library would still need to have their own AppConfig.h/JuceHeader.h files and all the other JUCE settings.

[cor3ntin]

@McMartin That's taken care of!

We wrapped JuceHeader.h in an header which defines the global settings, include all the juce headers corresponding to the modules included in the static lib, then the JuceHeader.h of the project consuming the static lib

[McMartin]

@cor3ntin That's exactly what I meant with "would not solve the whole problem", you need to add some custom hacks/workarounds.

[cor3ntin]

@McMartin we did, it works for us!

However, it is unclear to me how much of what we do can be generalized as it can only works if the set of modules and some global settings are the same for all targets consuming the static library.

The frameworks things is one of the few things we had to duplicate to make it work though. Other issue we had is that things like JUCER_VST3_SDK_FOLDER do not get set properly if juce_audio_processors is not included in the module list, so we had to do that manually, but that's not really an issue.