This adds a CMake cache entry to std_cmake_args specifying that the
function clock_gettime is not available on 10.11 in order to avoid
runtime errors such as
dyld: lazy symbol binding failed: Symbol not found: _clock_gettime
when the build system is confused by Xcode 8's weak symbols.
Other weak symbols on 10.11, which may merit the same treatment in the
future, can be found with
grep 'weak$os10.11' MacOSX.sdk/usr/lib/system/libsystem_c.tbd
It’ll only get printed for people getting updated to tags now and these
are people who haven’t run a `dev-cmd` so we want to air on the side of
telling them less stuff that will confuse them and assume people who
have manually made another `git` branch will know how to get back to it.
For tagged commits produces the output:
- `1.0.1`
For untagged commits with a dirty tree produces the output:
- `1.0.1-19-g23efbc5-dirty`
Performance:
```
git describe --tags --dirty 2> /dev/null
0.07s user 0.01s system 96% cpu 0.086 total
```
This means we can tag any commit without needing to manually remember
to bump the revision every time.
When exactly two versions of a package were installed, the uninstall
message should not read "Remove them all with...", since only one
version remains.
"Remove all versions with..." is flexible enough to avoid being
interpreted as grammatically incorrect, and it still accurately
describes the general behavior of `brew uninstall --force`.
- Don't let the `UPSTREAM_TAG` variable bleed into future repository
checks.
- Even if the tag branch is an ancestor of the tag ensure that it's
forced back to the tag anyway.
Rather than following every change on `master` let’s have non-developer
users (i.e. those who have never run a `dev-cmd` or set
`HOMEBREW_DEVELOPER`) update between tags.
This provides a fairly natural beta (the `master` branch`) and stable
(the tags) approach without restricting us to any particular way of
managing our tags.
If we have a `brew.sh` which has set
`HOMEBREW_ENABLE_AUTO_UPDATE_MIGRATION` then let's allow an auto-update
migration. That's because it contains the fix below it _before_ the
update happened which means the auto-update won't fail in the same way
as if updating from an old version.
ilovezfs