I was searching for a way to speed up build times and have come up with a nifty class/app that takes an existing Introjucer project, creates a copy of it, builds a single cpp file for all the sources and then disables compiling for all the individual sources. The result is effectively a JUCE module for your app. This really increases build times where file access is slow such as in a VM. One of my projects with a few hundred files went from 30mins to 5 mins build time. Here is a brief feature list:
[list]
[]Can set custom build folders for the new project so it doesn’t modify your original project[/]
[]Can split unity output file into a number of files for multi-core performance or if memory is an issue[/]
[]Can optionally re-save the Introjucer project to generate the build files without having to open up the project[/]
[]Can still browse and edit all your source files in the same way[/][/list]
I’ve found the quickest way to use this with a growing project is build a simple command line app something like (dRowAudio/Apps/UnityProjectBuilder):
[code]int main (int argc, char* argv[])
{
const StringArray cmd (argv, argc);
if (cmd.size() > 1)
{
drow::UnityProjectBuilder parser (cmd[1]);
parser.setNumFilesToSplitBetween (4);
parser.setLogOutput (true);
parser.setBuildDirectoryName ("BuildUnity");
if (parser.run() && cmd.size() > 1)
parser.saveProject (cmd[2]);
}
return 0;
}
[/code]
And then copy this into your project directory and create a script to run it. Then when you add files to your original project just run the script and carry on working in your unity build project. What would be neat is if you could add custom scripts to the Introjucer save procedure but that doesn’t matter for now.
#!/bin/bash
cd "$(dirname "$0")";
./UnityProjectBuilder "dRowAudio Demo.jucer" /Applications/Introjucer.app
Of course there are a couple of things to remember when using a unity build system like this. The most common is that you can’t create multiple instances of objects with the same variable name. This usually happens when you create global or static objects at the top of source files. As there is now only one translation unit everything will have to have a unique name. This is really an indication to scope things better however making them class member variables.
The other common pitfall is symbol clashes on Windows, most notoriously Rectangle. This often occurs when you use 3rd party libraries such as cURL or boost that include Windows headers. My advice on this is to wrap any 3rd party libraries in their own module and keep their includes away from the rest of your project. Also if you create a nice JUCE layer on top of a library please share it!
I’ve tested this on a couple of small projects including the dRowAudio and JUCE demos as well as some larger scale things and everything went well but you might want to take a copy of your projects first while testing it out as there is the potential to overrite some source files if you already have things named like UnityBuild or similar, anyway that’s what Git is for!
Here’s the source but the easiest thing to do is just grab the module (see sig).
Anyway, let me know if anyone finds it useful or has any feedback.
