Site navigation

Separate WrapperConfig.h header for wrapped plug-ins?

Audio Plugins
#1

Hi, I’m currently building (with Xcode) Juce as a static lib, and linking this lib against the compiled {plug-ins wrappers + plug-in code}.

In order to have all config generic, I use the common AppConfig.h header in the Juce lib (#define JUCE_MODULE_AVAILABLE_juce_* 1 […]), and a modified AppConfig.h with wrapper config macros when compiling the wrapper and the plug-in code (#ifndef JucePlugin_* #define JucePlugin_* […]).

That’s working well and cuts my compiling waitings by a great factor, given the fact that I’m building many plug-ins and often alter the modified AppConfig.h or switch branches which alter this header but not the juce modules’ AppConfig.h anymore.

However, this leads to a duplicate AppConfig.h header, and the dependency check of Xcode does not behave correctly with that. Could it be possible to move the wrapper’s config macros (JucePlugin_*) into a new separate header (say PluginConfig.h or WrapperConfig.h for instance) and include this only where required? I think it would be pretty clean because these plug-in macros are not related to the other juce modules.

All the best

#2

Not sure I fully understand what you’re asking for…

But I think it’s a very bad idea to allow any variations in the headers that you use. One of the reasons I hate and discourage static libs is because it’s so easy to link a lib into a target where the headers have been compiled with very slightly different options, and to end up with a binary that links ok, but which has subtle runtime data misalignments, causing horrible, hard-to-track-down bugs. You have to be scrupulous about building the lib and all your apps with precisely the same headers and options to avoid that kind of problem.

#3

Well, indeed that’s risky, but that’s the case with any 3rd party lib, isn’t it? The point of this proposal is just deporting plug-in related macros from AppConfig.h to a new WhateverConfig.h so that this is made possible (and not “just a little broken with xcode” anymore because of duplicate AppConfig.h in the project).

#4

So if I understand you correctly, you’re putting some of the juce modules in a static lib, but not the plugin wrapper modules, which you’re including as source-code? And then you’re building multiple binaries with different settings in each one and expecting it all to link without problems…?? My official opinion is that I did NOT design any of this stuff to be used like that!

All the code is written with the assumption that all the modules in a binary will have been compiled with exactly the same preprocessor settings, via AppConfig.h. Some modules contain code which makes hidden internal references to things inside other modules, so if you start linking together modules that were built with different settings, you do so at your own risk!

#5

I actually do this for my DISTRHO project.

I have a global AppConfig.h file that has all the module settings except for plugin_client. See:
https://github.com/falkTX/DISTRHO/blob/master/libs/juce-2.0/build-juce/AppConfig.h

Then when I need to build plugin binaries, I use the old JucePluginCharacteristics.h file, example:
https://github.com/falkTX/DISTRHO/blob/master/ports/juce-demo-plugin/source/JucePluginCharacteristics.h

I also have juce as a shared library… :lol:

#6

[quote=“jules”]So if I understand you correctly, you’re putting some of the juce modules in a static lib, but not the plugin wrapper modules, which you’re including as source-code? And then you’re building multiple binaries with different settings in each one and expecting it all to link without problems…?? My official opinion is that I did NOT design any of this stuff to be used like that!

All the code is written with the assumption that all the modules in a binary will have been compiled with exactly the same preprocessor settings, via AppConfig.h. Some modules contain code which makes hidden internal references to things inside other modules, so if you start linking together modules that were built with different settings, you do so at your own risk![/quote]

Well, as I said I want to use Juce as a static lib in multiple plug-ins.

As the plug-in specs are currently in the AppConfig.h as macros, if I did compile the plug-in wrappers into the static lib, that would have locked the plug-in characteristics once and for all: same name, same I/O channelcount, etc. That’s why I only build the wrappers along with each plug-in. By the way, all my AppConfig.h macros in the various projects are exactly the same as the static lib (except for the #define JucePlugin_*, not used in any of the modules compiled in the static lib).

I understand that you did not design Juce for this usage and I respect that, along with your warnings about the riskiness of doing that. But looking at the code architecture, I don’t see any reason why it would not actually work. The current proposal is just a way of separating config headers by role (the #define JucePlugin_* are only used in the wrapper sources). And this way, the risk of having different settings in the various AppConfig.h’s simply vanishes.

All the best

#7

I’m still really unclear about what you’re actually asking for though - can you perhaps give an example of the kind of thing you’d put in this new header file?

BTW, are you sure you really can’t do it without any changes? All of the JucePlugin_* macros are wrapped in #if statements to allow you to override them globally, so if you have multiple projects which are the same except for a couple of those macros, you could easily override them with preprocessor definitions in your project settings, or set them in the user-code section at the top of your AppConfig.h, e.g.

[code]//==============================================================================
// [BEGIN_USER_CODE_SECTION]

#if MYPROJECT_1
#define JucePlugin_Name “proj1”
#define JucePlugin_Desc “desc1”
#elif MYPROJECT_2
#define JucePlugin_Name “proj2”
#define JucePlugin_Desc “desc2”
…etc

// [END_USER_CODE_SECTION][/code]

?