Thanks for this, I didn’t know! I’ll have to create a module for JUCE now 
FWIW my recommendation is not to use static libraries unless you need to keep your code private, or incorporate difficult 3rd party libraries.
Re: long compile times, I’m amazed that you could have ended up with a 2 minute compile time for a cpp without it being a million lines long! But modules do allow you to have multiple cpps - I mainly just recommended a single one to stop people including all their cpp files separately the standard way, and because for the vast majority of modules, the code will easily be small enough for a single compile unit to be the optimal size. If yours is somehow taking 2 minutes then it sounds like you do need to split it up! (You’re not including boost are you? That’s often the culprit when compile times get long…)
If you include all your dependencies in one file, then yes, you may end up with a million line file. But then, a million line file may require 20 minutes to compile (the industrial app I’m working on, without as many templates as Audio ToolKit has more than a million line and it takes half an hour to compile it in parallel).
A static library makes sense if you don’t want to recompile everything because you don’t need the full package but only parts of it and only a few template instantiations.
I’m amazed that you could have ended up with a 2 minute compile time for a cpp without it being a million lines long!
When you’re including a header-only, “everything is a template” library, that’s easy to achieve 
In my case that’s RxCpp, and as you mentioned, boost is probably often similar.
But yeah, seems like I just need to split it up.
Hey,
i’m working on a parser that is supposed to help create cmake projects using juce. I’ve noticed that most of the attributes that a module can use are note used as of yet. (For example, platform suffixed source files or the searchpath attribute) Is this just a mean to get the module format future proof?
Different topic: Would it be possible to split the audio_plugin_client module in a base and the separate modules for VST2, AU and so on? While all other standard modules are super easy to manage, the plugin stuff needs to be includes manually which is a bit annoying. When I want to split the project in a static.lib and then dynamic libs for each API, I need to split up the module, use half of it in the shared code and parts of it in the final targets.
I use the Git submodule approach. No complaints if the “local copy” thing goes away.
Don’t reinvent the wheel
Yeah, I went over this repo already. There seem to be a few things that don’t work with what I have in mind. (But I might have got something wrong here)
First, it doesn’t look like it’s ready to go on Windows. Though I have to check that when I have time. More importantly, the part where it gets complicated, the plugin target part, seems to be a less flexible solution. All-in-CMake configuration rather then the projucers proxy-include method. I don’t like the proxy-includes but at least with that solution, I can make use of the preprocessor to handle some “project inheritance”. It also seems to generate one target per API rather then one static lib and then the “entry point only” target for VST, AU and so on. That’s only a compile time issue though.
Please keep the ability to make a local copy.
You should really be using git submodules at this point instead of local copies.
2 Likes