Ok, I’ve just checked in the first stage of the big move towards a modularisation of the library. Initially, I’ve done this on a GIT side-branch called “modules”, so that those of you who are interested can have a play around while I’m still finishing off any rough edges.
I’ll try to summarise the important changes:
[list]Instead of all the classes living in one big ‘src’ folder, there’s now a subfolder called “modules”, containing about a dozen smaller libraries.[/]
 Each of these modules is self-contained, but may have dependencies on other modules. For example, there’s a “juce_core” module upon which all the other ones depend, and modules while use GUI classes will depend on the “juce_gui_basics” module, etc.[/]
 In the root of each module’s folder, there’s a file called “juce_module_info”, which is a JSON description of that module’s properties. This contains instructions which the Introjucer uses to work out its dependencies, and describes how the module should be incorporated into a target project.[/]
 The introjucer has been re-written so that in your project settings, you specify a list of modules that you’d like to use in your project. You just tick the appropriate boxes, and it’ll generate the appropriate header inclusions and add the appropriate cpp files to your project so that the modules are magically available.[/]
 Configuration settings are no longer a global list - instead, each module has its own set of flags that you can change. Instead of the introjucer having a “flags” page, it shows the flags for each module when you select it on the modules page. (But these settings are still all written into your AppConfig.h file)[/]
 There will be no such thing in future as the amalgamated files or a global “juce.h” header. As a transitionary aid, I’ve created a bunch of files called “juce.h”, “juce_amalgamated.cpp”, etc, in the same locations as the old ones used to be, but if you look inside them, you’ll see that these are just wrappers that pull in the code from all the modules directly. The idea behind this is that a lot of old juce projects should still (perhaps!) compile without needing to be updated, although it’ll spit out compiler warnings telling you that the old style is deprecated. Once the new modules are established, I’ll get rid of these files altogether. (Note that old audio or browser plugin projects won’t still compile, because they also contain references to wrapper files which have moved to new locations in the tree).[/]
 For audio and browser plugins, all the wrapper code that used to be scattered around the tree and the extras folder has been cleaned-up into modules called “juce_audio_plugin_client” and “juce_browser_plugin”.[/][/list]
To transition your old projects, hopefully all you should need to do is to open them in the new Introjucer, and re-save them (probably better have a quick look through the module list and check their config settings though, as some of these may have had to change slightly). Browser plugins are a bit more of a PITA because the introjucer doesn’t handle them - for those, have a look at the way the demo plugin’s project is constructed, and copy that, or ask me for help. In the long-run, I have a better plan for handling these, which I’ll explain later…
Obviously with a re-organisation of this scale, it’s inevitable that I’ll have forgotten or missed some details, so I’d really appreciate your feedback - if anything doesn’t work or doesn’t seem to make sense while you’re trying to transition, please shout!