Page MenuHomePhabricator

build: macOS toolchain simplification and bump
ClosedPublic

Authored by Fabien on Oct 2 2020, 11:29.

Details

Reviewers
deadalnix
Group Reviewers
Restricted Project
Commits
rABCa8598eced57d: build: macOS toolchain simplification and bump
Summary
This PR achieves 3 main things:

    It simplifies the macOS SDK generation by putting the logic inside a
(semi-)portable python3 script gen-sdk
    It transitions us to using libc++ headers extracted from the
Xcode.app, which is more correct as those headers better match the .tbd
library stubs we use from the MacOSX.sdk (located under the same
Xcode.app). Previously, we used libc++ headers copied from our
downloaded, pinned clang (see native_cctools.mk).
    It bumps the macOS toolchain in a way that fulfills all of the
following constraints:
        The new SDK should support compiling with C++17 (our current one
doesn't)
        The new toolchain should not change our minimum supported macOS
version (-mmacosx-version-min)
        The new toolchain should expect to use a version of cctools that
is supported by https://github.com/tpoechtrager/cctools-port

For the constraints in (3), you can reference this chart to see that the
newest toolchain we can use with our cctools-port is 11.3.1, and the
rest of the constraints were tested with local builds.
But the other Wikipedia chart says that the "min macOS to run" for Xcode
11.3.1 is 10.14.4, doesn't that violate constraint (ii)?

This confused me at first too, but the "min macOS to run" is for the
Xcode.app App itself. The SDK still supports 10.12, as evident in a few
plist files and as proven through local builds.
Why bundle all of this together in a single PR?

We need (1) and (2) together, because if we don't, manually adding the
libc++ headers and writing that out in a README.md is going to result in
a lot of user error, so it's great to have these together to be more
correct and also make it easier on the user at the same time.

We need (3) together with everything else because bumping (or in the
case of (1), renaming) the SDK requires some human coordination and may
break some builds. And since it's not that complicated a change, it
makes sense to do it together with the rest.

Backport of core PR19240.

Changes from the original PR:

mono-repo and update the doc accordingly

  • Update the gitian.sh script for our CI.
  • Adapted the build for cmake
Test Plan

Extract the SDK as per the instructions.

make build-osx

cmake -GNinja .. -DCMAKE_TOOLCHAIN_FILE=../cmake/platforms/OSX.cmake
ninja

Send the resulting BitcoinABC-Qt.app to some OSX machine and run it.

Run the OSX Gitian build twice on different machines and check the build
is still deterministic.

Diff Detail

Repository
rABC Bitcoin ABC
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Fabien requested review of this revision.Oct 2 2020, 11:29

[Bot Message]
One or more PR numbers were detected in the summary.
Links to those PRs have been inserted into the summary for reference.

deadalnix requested changes to this revision.Oct 2 2020, 14:15
deadalnix added a subscriber: deadalnix.
deadalnix added inline comments.
contrib/apple-sdk-tools/LICENSE
1 ↗(On Diff #24200)

Why is this for? This isn't in the PR and there is already a licence file at the root.

This revision now requires changes to proceed.Oct 2 2020, 14:15

ok the licence comes from the 3r party project being imported.

This revision is now accepted and ready to land.Oct 2 2020, 18:57