I would like to know if there is an howto that explains the usage of JUCE_DLL and JUCE_DLL_BUILD=1 . I did find anything on the JUCE documentation.
I would like to create a couple of DLLs that export some components and to use them in another JUCE Gui application.
It’s probably easier to just add the source code for the components directly into the application project. What benefit do you expect to get from using dlls?
One of the reason is that I want to write unit tests. Every time I need to create a new class in my library, I will have to add the source code of the class in the test runner application and in my main application. Using shared libraries is also more efficient during the development for large scale project.
JUCE_DLL_BUILD=1 should work. Another option is to put all your framework type code into custom JUCE modules and then add those modules to the unit test runner. We have quite a large code base with ROLI’s NOISE app and this is how we keep things sorted and tested. Another plus with modules is that you can easily unit test with different compiler flags.
I managed to use the JUCE_DLL_BUILD and to use the generated DLL in a JUCE App in which I removed all the JUCE modules. But in the application projucer project I had to remove all JUCE modules and to add a extra include path be able to use JUCE classes. I also added JUCE_DLL in the application projucer project.
I’m a newbie with JUCE so I was not aware of the custom_module. I quickly tried to use that projucer feature and I think that it is probably the “standard” way to do what I want in the JUCE environment. I will continue to investigate that solution.
Thanks Fabian for your advice.
Here is another post discussing the same topic:
The issue when I use the custom module is that every time I change the code of a class within the custom module, the entire custom module is recompiled due to the fact that for each custom module, only one compilation unit (cpp) file is compiled. It could be very time consuming during the development depending on the number of files in the custom module.
Yes that is true. But that may really depend a lot on the structure of your code. Take JUCE for instance: the
juce_gui_extra module pulls in quite a lot of headers from the other modules. If we would split this into many small cpp files then there wouldn’t be much speed-up as a significant amount of compiler time is used just parsing all the headers (which is needed for every single .cpp file). Putting all the .cpp files into a single module doesn’t actually increase the compilation time vs. the time it takes to compile a single .cpp inside the module - often it’s under half a second. Plus, you get the additional flexibility that all the cpp files in one module can refer to identifiers in other cpp files without needing to declare these in headers.