Creating general libraries - include file issue

Hi all,

Although I’m a relative newcomer to JUCE, I’m an experienced C++ developer, otherwise used to creating generic libraries of re-usable components.

On initial examination, there would appear to be some obstacle to achieving this with JUCE: specifically on the basis of the statement in the generated (and end-application-specific) ‘JuceLibraryCode/JuceHeader.h’:
This is the header file that your files should include in order to get all the
JUCE library headers. You should avoid including the JUCE headers directly in
your own source files, because that wouldn’t pick up the correct configuration
options for your app.

I’m not sure what the consequences are of ‘not picking up the correct configuration’, but
this would appear to be at odds with the need for the (ideally, pre-compilable) source files in a generic library to have visibility of the JUCE headers.

One workaround would be for libraries to be ‘header only’ and have them rely on end application source files to #include them only after having #include’d .“JuceLibraryCode/JuceHeader.h”.

However, this would be brittle and hence undesirable.

Is there some better recommended practice in such cases?

Just go and change the generated path into the “JuceHeader.h” file only and all should be good…

Thanks, but AFAICS, this would still preclude pre-compiled library source, if the ‘correct configuration’ of the end application differed from that of the library. Is that not so?

Can anybody enlighten me as to when an ‘incorrect configuration’ might arise and what the consequences might be?

I think the JuceHeader.h is here to guarantee that AppConfig.h is included before the modules headers (for instance juce_core.h, juce_events.h, …). AppConfig.h potentially defines dozens of pre-processor macros, which are then used by the headers (and the source files) of the modules. If you don’t include JuceHeader.h/AppConfig.h in one of your .cpp file, then these pre-processor macros won’t be defined and you might get an “incorrect configuration” problem.

If you know exactly what you are doing , i.e. which pre-processor macros are defined where and when, then you should be fine including the module headers directly.