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 current options are:
-b/--benchmark Run benchmarks instead of tests.
-m/--measure Measure time of each test. This disables concurrency.
-r/--repeat <n> Number of times to repeat each test/benchmark.
-v/--verbose Be verbose.
-h/--help Show this help.
-V/--version Show version number.
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.
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.
