This slows down signing enormously (10+ seconds) and fails most of the time when internet connectivity is suboptimal (might be related to being behind a proxy).
The problem is that with a bad internet connection there is a very high probability that “codesign --deep” will fail due to having to contact the timestamp server for each embedded executable object.
Long-term we probably want to sign the sub-targets as they are produced and/or link the entire thing together so that there is only a single sign target (plus embedded plug-ins).
This is required when signing on OS X 10.9.
Although the option is not documented for the version of codesign included with 10.8, using it does not result in an error.
Closes#1158
Use APP_VERSION instead of APP_REVISION in various target names.
Indicate a few build commands are generators, so that their output is not removed on ‘ninja -t clean’.
Move generated dummy files (for tagging, uploading, deploying, etc.) to sub-directories to reduce noise in build directory.
@executable_path is the originally-executed program, whereas @loader_path is the program that caused the load to occur (e.g. a Quick Look generator). @rpath can be changed at link time — a QL generator can specify a value that points to the enclosing app bundle’s Frameworks directory.
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.
