A suggestion to solve plugin installer bloat since abandoning the polymorphic plugin build

Since JUCE switched from the polymorphic plugin build (same file functions as AU/VST/VST3/AAX/RTAS) to building separate targets for different formats, plugin installer sizes increased by a factor of about 4.

I understand that reverting to the polymorphic build is not a good option (because separate targets are needed for stand-alone, which is not a library, and AUv3).

So I suggest a different scheme that will yield the space savings of the polymorphic build, not only in the installers but also on the customer’s hard drives -

Build a library for the shared code, for which the only entry point / exposed symbol is createPluginFilter, which will to be installed in some common folder (i.e Application Support/), where the different targets for the plugin formats depend on that library for the symbol providing them with the actual AudioProcessor.

Do folks think that this is a good idea?
If so, should this be an option in the Projucer, or should it be the way to do things?

I’m willing to implement this scheme, and contribute it to JUCE if ROLI’s willing to accept it. In any case if I’ll implement it, it will be available in our branch (which anyone which can use JUCE can use freely)

I see that the shared code used to be a shared framework after the initial transition from the polymorphic build.

And I guess perhaps it can’t be just exporting createPluginFilter like I suggested before because both the wrappers and the shared code use JUCE and all its classes…

Yes. The main issues with the shared framework were the inability to strip unused code and the inability to strip symbols. The shared framework on OS X was huge, so the space cost of having multiple binaries after switching to static linking wasn’t that big.

1 Like

But it’s still a factor of about 4 (varies depending on number of formats supports etc) on the polymorphic plugin build.

Then I guess it is not a good idea.

No! A lot of potential hassle without solving a real problem.

No, because a shared framework with everything JUCE in it is vastly bigger than one dead code stripped statically linked binary that only has the parts of JUCE that are really needed.

Unfortunately I also recall issues with building with certain copy protection libraries/tools back when the change was first made and it seemed the preference was to link in the static library with each format.

1 Like