I'm trying to compile the DLL for Juce so I can simplify accessing JUCE libraries and Headers in Visual Studio and other IDEs and for some reason I keep getting the following error when I open the JUCE DLL project and compiling it:
c:\program libraries\juce\modules\juce_core\memory/juce_ContainerDeletePolicy.h(58): error C2248: 'juce::AudioProcessorValueTreeState::SliderAttachment::Pimpl' : cannot access private struct declared in class 'juce::AudioProcessorValueTreeState::SliderAttachment'
c:\program libraries\juce\modules\juce_audio_processors\utilities/juce_AudioProcessorValueTreeState.cpp(377) : see declaration of 'juce::AudioProcessorValueTreeState::SliderAttachment::Pimpl'
c:\program libraries\juce\modules\juce_audio_processors\utilities/juce_AudioProcessorValueTreeState.h(143) : see declaration of 'juce::AudioProcessorValueTreeState::SliderAttachment'
c:\program libraries\juce\modules\juce_core\memory/juce_ContainerDeletePolicy.h(47) : while compiling class template member function 'void juce::ContainerDeletePolicy<ObjectType>::destroy(ObjectType *)'
with
[
ObjectType=juce::AudioProcessorValueTreeState::SliderAttachment::Pimpl
]
c:\program libraries\juce\modules\juce_core\memory/juce_ScopedPointer.h(100) : see reference to function template instantiation 'void juce::ContainerDeletePolicy<ObjectType>::destroy(ObjectType *)' being compiled
with
[
ObjectType=juce::AudioProcessorValueTreeState::SliderAttachment::Pimpl
]
c:\program libraries\juce\modules\juce_core\memory/juce_ScopedPointer.h(100) : see reference to class template instantiation 'juce::ContainerDeletePolicy<ObjectType>' being compiled
with
[
ObjectType=juce::AudioProcessorValueTreeState::SliderAttachment::Pimpl
]
c:\program libraries\juce\modules\juce_core\memory/juce_ScopedPointer.h(100) : while compiling class template member function 'juce::ScopedPointer<juce::AudioProcessorValueTreeState::SliderAttachment::Pimpl>::~ScopedPointer(void)'
c:\program libraries\juce\modules\juce_audio_processors\utilities/juce_AudioProcessorValueTreeState.cpp(429) : see reference to function template instantiation 'juce::ScopedPointer<juce::AudioProcessorValueTreeState::SliderAttachment::Pimpl>::~ScopedPointer(void)' being compiled
c:\program libraries\juce\modules\juce_audio_processors\utilities/juce_AudioProcessorValueTreeState.h(152) : see reference to class template instantiation 'juce::ScopedPointer<juce::AudioProcessorValueTreeState::SliderAttachment::Pimpl>' being compiled
I understand that the error seems to be that the Pimpl is not accessable since it's "private" but I'm not sure what's trying to access it that shouldn't be.
One floods my project directory with cpp and header files, the other is a single line which the deployment program reads to copy the dll to the build directory making everything work seemingly automagically.
In this case, skunks smell pretty fresh.... but thanks for your utterly unhelpful and assinine comment anyway.
Sorry, that probably sounded more sarcastic than I intended, but I've seen this kind of approach many times over several decades, and it's really not as simple as just magically linking to the DLL in one step - you really are opening up a world of pain by doing down that route!
The only good reason I can think of for using a DLL (and the only reason we still support it) is for complex projects involving some kind of plugin architecture where there are multiple dynamically loaded modules, in which you need to pass juce-based c++ objects between them. Otherwise it's just a total nightmare to build and deploy a project that way. If your only reason is to get better intellisense in Visual Studio, then it's a decision you'll regret!
But since the majority of juce users will be building either cross-platform apps or multi-format plugins, any kind of library tends to become a burden once the number of build targets goes up.
I've tried many different ways of structuring projects, and so far for the kind of things I've worked on, nothing beats "just add the source files"!
Jules: I'm sorry I took it more offensively than you meant it.
yfede: I would even take a static lib, the #pragma comment (lib, "*") method I think works with that even.
What I'm mainly doing is I'm trying to set up JUCE so that I can access it from QtCreator specifically but I'm trying to do it right so I don't have to manually add special configuration with every project to automatically look at it. So since I use the visual studio 2013 Community edtion cl compiler, and it references both the INCLUDE and LIBDIR environment variables I figured that I'd just add the appropriate lines to those.
QtCreator's rendition of the intellisense concept uses the same thing IIRC to give guidance on include files, and then scans the include file and it's subsequent includes to know what types to highlight and list in it's "intellisense".
I added boost that way, as well as a couple other libraries and they seem to work, but with JUCE, it's different... there's cpp files all over the place in the modules folder which I assume the projucer is meant to handle for you when you use it as your IDE. My hope was to compile a dll/lib that I could link against that contained all the juce implimentations (or even multiple dlls/libs) and then link to the "modules" directory for the include so that I could do for example:
#include <juce_core/juce_core.h> // this line would "just work" in any IDE since the INCLUDE env var is system wide
#pragma comment (lib, "juce.lib") // this line would also "just work" and compliment the former by making sure that the implimentation is linked into the executable.
I'm mainly more concerned about using the sound processing libraries than anything and I don't need it necessarily to be cross platform since I primarily use windows.
Maybe I'm trying to go about making linking easier the wrong way? but regardless that's what I'm trying to set up.
I've no ideas about improving the Qt Creator experience, as I've never used it, but FWIW something I want to do very soon is to refactor the way module inclusion happens, to reduce dependency on the introjucer and make it easier to build with other systems. It'd take too long to explain here exactly what that will entail, but I'll publish some ideas soon..
