For example we may specify a transform for ‘.rl → .cc’ and another for ‘.mm.rl → .mm’. For a file named ‘fsm.mm.rl’ the build system would use the first rule seen, now it will always pick the latter, as it matches more of the suffix.
The default for ragel is to generate compact and flexible code, not an issue for our current use case (parsing only comments and strings in ASCII property lists) but in the future we may need to tweak the output as ragel will be used for other things.
I think it will prevent multiple tests from being run in parallel, but when writing tests, we may produce a lot of output, that should not be buffered by ninja.
A future improvement could be to only use the console pool for the tests of the current target, but that will require two different rules to run tests.
This is because third party framework headers are likely to be installed in directories with many other headers that can clash with some of our custom frameworks.
Closes#1441.
We don’t care about the trim mode as nobody is reading the generated HTML, but we have to supply something, previously we enabled everything, which is now giving an error despite the documentation saying that trim mode can be “one or more of the following modifiers”:
% enables Ruby code processing for lines beginning with %
<> omit newline for lines starting with <% and ending in %>
> omit newline for lines ending in %>
- omit blank lines ending in -%>
It would seem that ‘<>’ is mutually exclusive with ‘-’ so now we pass ‘%-’ for trim mode.
This is because we ensure that each target copied to another target, gets signed before we copy it.
We initially used ‘-deep’ but that actually never worked fully, as it didn’t find all executables in our bundle, presumably only embedded bundles like frameworks and plug-ins were found and signed.
This is because we rely on `-X` (skip extended attributes / resource forks) which is only available with Apple’s version of `cp`, and it is not unlikely that the user has GNU’s version of `cp` available via PATH.
This is to avoid redundancy as ninja_required_version is hardcoded in the generator script and builddir is already passed via the --build-directory/-C option (and explicitly exported as a variable in the generator script).
There may be situations in which the user already have (generated) ninja build files which do not match our assertions.
This reverts commit b42cbb1f7e.
This seems like a logical separation, as the build directory now contains things 100% generated, whereas the “local” build file has variables that came from the original ./configure step and may be edited.
This is required because copying an executable to the build directory now depends on its signature, but the signature’s date is always newer (or same) as the executable being copied, which leads to the target being considered out-of-date and thus rebuilt (copied again).
This may seem non-standard but since presence of a variable in our target file will drop a potential -D when, it does not make sense to have -D take precedence over what is in the target file.
Ideally we would have a section with “public” variables, but that will require making the format more complex, so for now, everything gets declared as a variable in the ninja build file, even though for now, we really just need to export APP_MIN_OS.
The signature step takes the bundle as input and therefore depends on this, but if the bundle does not already exist, ninja will (correctly) complain that there is no rule to create it.
For bundles the sequence is now the following:
- Copy/run depends on signature
- Signature depends on bundle
- Bundle depends on linked executable and all resources
This changes a bunch of things:
1. Each framework now creates its own include directory for exported headers, and any target linking with this framework, gets that directory added to its include search path. This ensures deterministic behavior, unlike previously where a single shared directory was used, so even if target A did not explicitly link with target B, there was a reasonable chance that target B’s headers would be available when target A was built.
2. There is a new IMPORT keyword to indicate that a target depends on the headers of another framework but does not want to link with it. For example the `commit` shell command imports headers from the CommitWindow framework (related to their communications protocol) but linking with the CommitWindow framework would not be practical (as that would bring in all the resources of the CommitWindow).
3. All embedded targets are signed before being copied to their destination.
4. A new CS_ENTITLEMENTS keyword allows specifying `codesign` entitlements. Currently the hardened runtime is enabled, although this does make development problematic, as modifying files of a running instance (as done during rebuild) can cause TextMate to crash with EXC_BAD_ACCESS (Code Signature Invalid). Worse though, it seems the system has a cache of blacklisted executables indexed by inode. So if e.g. the embedded `mate` executable gets blacklisted, one has to manually remove and rebuild it, before it gets possible to use it again (by default, rebuilding causes the inode to be re-used, but I may change the build system to unlink before copy).
5. The build file no longer contains rules related to deployment. Instead variables are declared that a user build file can reference to extend the build with notarization/deployment rules (without having to hardcode build directory paths).
6. The code has been made modular with a Compiler super class that is subclassed to add support for file transformations (xib, ragel, asset catalogs, etc.) and a transformed file can have its own settings.
7. If target A links with target B, the linker flags of target B will now be included when linking target A.
8. Currently no indexing of help books. Unsure if this is actually useful.
9. Previously it was possible to have umbrella targets that would not generate any output, but just change settings for their sub-targets. This is no longer supported, as the implementation was arcane. I would like to introduce a different system for managing sectioned settings. Related to this; settings in target files are now always merged, regardless of whether using ‘=’ or ‘+=’.
We compile all assets into one file that resides in the main app bundle so while we can have multiple asset catalogs (per Framework, etc.), individual assets should still be namespaced.
