Now that we know that AppConfig.h needs to be included before juce headers (or else this issue occurs: http://www.rawmaterialsoftware.com/viewtopic.php?f=2&t=8878), a problem comes up when designing a library. Consider the following projects:
FancyLibraryProject
A static library project of really useful classes built on top of Juce. Includes AppConfig.h by necessity, before the Juce headers. Does not include the Juce module sources, since they are added to the host application project instead.
CommandLineTool
A command line tool project that uses FancyLibraryProject, but does not use Juce directly. Includes the necessary Juce module sources in the project.
GuiApp
An executable project that uses FancyLibraryProject, as well as Juce. Includes the necessary Juce module sources in the project.
The question now becomes, where does AppConfig.h go? We can’t put one in each of the executable projects, or else FancyLibraryProject would have a backward dependency. Besides, which AppConfig.h would it use? If we put AppConfig.h in FancyLibraryProject then we can’t have different Juce build settings for projects that depend on the static library.
So in your library you have a search path leading to the application? That’s a reverse dependency. Or do you mean that you use the AppConfig.h that comes with Juce? Because that is not supposed to be used for your project…you’re supposed to make your own copy and point your compiler at it.
If you have a static library with AppConfig.h somewhere, then two different applications can’t use different AppConfig.h with that library.