I prefer the YYYY-MM-DD format of our custom macro, but it has a problem with precompiled headers in that the macro changes value daily, and so, if specified when precompiling headers, they become invalid the next day.
Previously we solved it by declaring the macro only for application targets, but the new build system is not hierarchical in the same way and does not currently support this.
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 ‘+=’.
The use case for this feature is when an interactive rebase is in
progress and be able to, in one command, amend the current commit
and continue with rebase.
By default, if the --rebase-in-progress flag is passed when the
"commit" command is invoked the commit button will be in a
"commit and continue" state. This is indicated by the title of the
commit button now being "Commit & Continue". If the option (⌥) key
is being hold down the state will revert back to the standard "commit"
state and the title will change to "Continue".
If the butten was clicked when it was in the "commit and continue"
state the "commit" command will print "TM_SCM_COMMIT_CONTINUE=1"
(without the quotes) to stdout as the last line. If the button was
clicked when it was in the standard "commit" state the output may
contain "TM_SCM_COMMIT_CONTINUE=0", or the "TM_SCM_COMMIT_CONTINUE"
string will be absent.
This was just mirroring the last part of our version number so redundant and it wasn’t monotonically increasing as we switched from alpha.n → beta.1 (with n > 1), so it probably did more harm than good.
This allows the commit command line tool to open a window as “native”.
We use distributed objects for talking to TextMate and getting a response. For the response, we release the connection in the next iteration of the event loop and then gracefully exit the program. Though it’s not clear if this is enough time for distributed objects to reply the client (if not, an exception is thrown in the client about “connection disappeared while waiting for a reply”).
