Jucequake Part 1

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!

…and FYI, I’d also like to give a summary of what’s to come in the further adventures of the ‘Jucequake’!

In “Jucequake Part 2”, you can expect the following:

[] The modules will be available as zipped bundles, and the introjucer will be able to download them directly from the website.[/]
[] The module description files will be able to contain scripts (probably using Javascript) which let them perform custom behaviour when generating the target projects. This means that e.g. the juce_audio_plugin_client module will be able to take care of setting all the appropriate project settings to create an audio plugin itself, rather than in the current system, where the introjucer contain special-case code to handle audio plugins, etc. This means that all types of non-standard targets, e.g. different audio plugin formats, browser plugins, photoshop plugins could be written as self-contained modules, without requiring special code in the introjucer.[/]
[] You’ll be able to choose whether your project compiles each module by referring to the module’s source files in some juce folder on your disk (as it does currently), or whether a copy of the module should be made directly inside your own project tree. This option will make it easy for your project to be entirely self-contained, and not to have any references to files outside its own folder. That means that you can just check the whole thing into source-control and not need to worry about your project referring to an external juce folder which may or may not have moved or changed.[/]
[] There’ll be command-line tools for controlling the introjucer, generating projects, updating modules, etc.[/][/list]

Once all of this is in place, it’ll be possible to start thinking about adding 3rd-party libraries - the juce website will contain a master list of modules, which needn’t consist only of my own work, and other people could offer zipped modules on their own websites. To publish a new module will be as simple as adding it to the website’s master-list, and for people to use it will just involve ticking the box in the introjucer, which would automatically download it and add it to your project. This ease of delivery would make it a fantastic way to give access to open-source libraries that can be a bit of a PITA to install - e.g. FFMPEG, boost, embedded scripting languages like Javascript, Lua, Python, etc.

So that’ll be Jucequake Part 2. I also have a more ambitious plan for where this is all heading, but details of Jucequake Part 3 are currently secret!

BTW, someone asked how to get the new branch using GIT. Here’s what to do:

git clone --depth 1 git://juce.git.sourceforge.net/gitroot/juce/juce cd juce git checkout -b origin/modules

…and a further note - apparently “git checkout -b origin/modules” doesn’t work for some people. Odd, because it did work for me. Ah well, if you have trouble with it, you might need to just do:

And an update to this:

I’ve now merged the modules branch into the master branch, so all of this stuff is now irrelevant! To get the latest code, please just pull from the normal master branch, no need to worry about git branch commands!