Variables which are not referencing other variables are no longer provided with their literal value. Variables which do reference other variables have the reference escaped, so that ninja won’t expand the reference when rebuilding build.ninja.
There is still some redundancy in that APP_VERSION has the major + tag part stated both at the top and as a command line argument, haven’t yet figured out how to best deal with this.
The motivation for introducing a new test generator is that CxxTest cannot be used with tests that (indirectly) schedule code to run in the main queue.
There are a few other advantages of breaking with CxxTest:
1. Less boilerplate: A test file need only contain a
function named with a ‘test_’ prefix. No classes,
inheritance, or similar. If you need fixtures, use the
multitude of ways that C/C++ allows that (constructor
functions or non-POD types with static storage).
2. Concurrent tests: Test functions are scheduled with
‘dispatch_apply’ and will thus run concurrently. If
you need serial execution you can wrap your tests in a
block and schedule that to run in the main queue.
Though you should catch exceptions and re-throw these
in the test’s original queue, as the test assertions
are using exceptions.
3. Easier output of custom types: The assertion macros
will call ‘to_s’ on the arguments given, so the only
thing required to make these output nicely is to
provide a ‘to_s’ overload for your custom type /
enumeration. I know that the standard way to do this
is overloading operator<< for a stream, but the
TextMate code-base already uses the ‘to_s’
convention.
Long-term I can see a few other advantages, like calling preprocessor on the input files to support #if/#else/#endif to disable tests, better support for Cocoa code (NSRunLoop), and introducing test timeouts.
Turns out a phony rule in ninja isn’t exactly the same as an alias. When the file the phony rule is supposed to be an alias of already exist when calling ‘ninja’ then rules depending on the alias are not considered out-of-date even if the aliased file is of newer date.
Build rules that previously depended on ‘after_bump’ should instead depend on ‘builddir/revision.$APP_REVISION’.
Some users have reported issues opening TextMate: Finder tells them the program is corrupt and should be moved to trash. If the user adds his own (ah hoc) signature, then no such dialog is shown.
This reverts commit 1c164e3ce0.
This means that the signature will be invalid when the certificate expires, though it also means that codesign runs faster, and as my certificate is valid for another 4 years, people shouldn’t be using the builds released today when the certificate expires.
This target is solely intended for other targets to depend on, and will cause the dependents to be rebuilt after the APP_REVISION has been increased.
For example ‘Contributions.md’ technically depend on commit history (and online lookups), but in practice we can’t specify this in its dependencies, so previously we had to manually touch the file, if we wanted the HTML to be regenerated.
Now we can have it done automatically after each ‘bump’ by adding this rule:
build path/to/Contributions.md: touch | after_bump
For the records, I bump the revision *before* I do ‘ninja deploy’. This ensures that deployed versions do not share revision number with a custom build (I do another ‘ninja bump’ after a successful deploy and ./configure will also set APP_REVISION to ‘current + 1’).
This is just to make “bumping” the revision safer. Previously the revision number would be two places in the generated build file, and both needed to be bumped. Now there is only one instance. Generally the revision is bumped with ‘ninja bump’ so the user shouldn’t care about it, but sometimes manual intervention is required.
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.
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.
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.
