Previously if we did something like:
CP_Resources = resources/*
The build file would correctly depend on the ‘resources’ directory, but a change, as in, adding, removing, or renaming a file, in a directory below ‘resources’ (e.g. adding ‘resources/English.lproj/NewWindow.xib’) would not correctly update the build file to include the new resource.
If e.g. we rename “image.tiff” → “image.png” then the build files are correctly updated to copy “image.png” to the build directory, but until this commit, the old tiff image would stay in the build directory until manually removing it / cleaning the build directory.
It now takes key path and destination (github repostiory) as arguments. The generated build.ninja assumes the user local build.ninja sets these variables.
This means having a test file open (in TextMate) and using ⌘B, the test will always run, even if it has previously succeeded and none of the test’s dependencies have been updated.
Motivated by a lot of “where is the syntax highlight?” questions from users that build from source, we now always create the DefaultBundles.tbz (if it doesn’t exist).
Since ninja run each build job with its own stdin/out/err we can’t launch gdb itself in a build job, so we use osascript to launch gdb in a new window.
I used Terminal for this only because it is simpler to script than iTerm2.
Previously we wrote out the build rules alphabetically and grouped by target type. So e.g. the build rule for a framework would be created before that of an application bundle.
While it worked, it didn’t allow e.g. the preferences framework to depend on the mate executables (for copying to its resources section) since the build rules for mate would be created after that of the preferences framework.
We now do a topological sort on the dependency graph (by shelling out to ‘tsort’) to make the build system more flexible.