JSON should be a subset of YAML so we use ruby’s YAML parser to parse GitHub’s JSON. This however leads to syntax errors reported by the parser (as noted in issue #637) but if the JSON is “pretty printed” it seems to parse it fine (seems to be the extra white space for associative array pairs).
We can trick GitHub into pretty printing the JSON result by setting the user agent to be curl, so that is all this workaround does.
We now explicitly disable it for targets that hasn’t yet been upgraded to ARC. This way, it’s easier to get an overview of which targets hasn’t yet been upgraded and ensures new targets has ARC enabled.
This avoids depending on the user having installed the JSON gem (and fixes problems where user has it installed, but for a different ruby than the one used to run this script).
This is when generating HTML for the release notes, manual, and, where we actually need this, list of contributions.
Long-term we should probably switch to template tags as we are effectively adding code to the (otherwise declarative) build graph, which means we don’t have any way to tell if the generated HTML is up-to-date or not (as that would require analyzing the embedded ruby code).
We no longer do an implicit bump after deploy — this should be done, but as we also want to do a bump before deploy (so deployment builds do not share revision with any custom builds) we need the bump rule to be usable by itself.
Also fix issue with bumping APP_REVISION in build.ninja not affecting APP_VERSION after rebuilding build.ninja.
And additionally include user file after main build.ninja.
The issue is that the precompiled header must also be created with ARC enabled, so now we use different precompiled headers depending on wether or not the file to be compiled has -fobjc-arc enabled.
The way this is done is hardcoded for the ARC options, it might be nice to abstract it so that the PCH dependency had a name derived from the PCH-sensitive compiler options.
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.
