Recently I’ve been thinking about how I could simplify the library’s structure a bit, with two aims in mind:
- To cut down all the multitude of static/inline/amalgamated etc ways that you can link to juce
- To make it easier to use just the bits that you need, and avoid the overhead of pulling the entire library in if you only want to use a few classes.
So, I’d be keen to hear people’s views, but what I’m considering would be something along the following lines:
- ditch the static library versions altogether. (And any remnants of the DLL builds). Ok, I know some people have been statically linking to it, but you could still create your own side-project that put it inside a static or dynamic library if you really need to, that’d be easy to do. I can’t actually think of any advantages whatsoever in statically linking - normally it’s used because it’s easier than including all the hundreds of source files in each project that uses them, but since juce fits into a single source-file, adding it to a project is trivial, and the extra layer of using a library and setting up the library paths, having different binaries on each platform, with different compile settings, etc just outweighs any advantages. If you have a killer use-case for static linking, I’d be keen to hear about it.
- ditch the amalgamated files and instead simply provide a juce.cpp (and juce.mm) file alongside the juce.h header. So to use it, you include juce.h in your code, and add juce.cpp to your project. Job done. No further instructions required.
- for building just parts of the library, there’d also be a range of other headers: probably things like juce_threads.h juce_audio_devices.h, juce_components.h, etc. So rather than including the full juce.h, you could just include the bits you need. Obviously some of these sections would be dependant on other ones, but it’d be a way to let you just pull in the minimum possible for what you’re doing.
- Internally, there’d be a bunch of macros like JUCE_BUILD_COMPONENTS, JUCE_BUILD_AUDIOFORMATS, etc, to control the bits that get included, so you could also include juce.h after having set up some flags to indicate which bits you want to use, and that’d have the same effect as including the different header files.