commit | 4005bb741040c2c02c9c5757457bb4c548cfe348 | [log] [tgz] |
---|---|---|
author | Mark Mentovai <mark@chromium.org> | Thu Sep 24 02:20:04 2020 +0000 |
committer | LUCI CQ <infra-scoped@luci-project-accounts.iam.gserviceaccount.com> | Thu Sep 24 02:20:04 2020 +0000 |
tree | bd01a1bf926cc97bffcbe938b57bd2b22c7fefcf | |
parent | d1580d53b7bc1f244d4eaf797aca0d066fad166c [diff] |
mac-arm64: Provide an arm64-native ninja-mac for builds in ¼ of the time ninja-mac is expanded to become a universal (“fat”) executable. The existing x86_64 slice was taken from the x86_64 ninja-mac as it previously existed in this location, and a new arm64 slice was added. This is an aid to native development on arm64. In macOS, subprocesses inherit their parent’s “binpref,” meaning that children of a translated process will, by default, also be translated, if there’s a choice between native and translated. Where ninja-mac is x86_64-only and runs translated on arm64, all tools it invokes will also run translated, even if native versions are available. This has an impact on any part of the toolchain for which universal versions are available: in Chrome’s case, tools such as ld64 are affected. In Crashpad’s build, which uses the compiler provided by Xcode, it even affects the compiler, leading to significant differences in build time on arm64. mark@arm-and-hammer zsh% file $(which ninja-mac) …/ninja-mac: Mach-O 64-bit executable x86_64 mark@arm-and-hammer zsh% time ninja -C out/release ninja: Entering directory `out/release' [1/1] Regenerating ninja files [511/511] LINK ./crashpad_minidump_test ninja -C out/release 1384.03s user 111.05s system 393% cpu 6:19.53 total mark@arm-and-hammer zsh% file $(which ninja-mac) …/ninja-mac: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] …/ninja-mac (for architecture x86_64): Mach-O 64-bit executable x86_64 …/ninja-mac (for architecture arm64): Mach-O 64-bit executable arm64 mark@arm-and-hammer zsh% time ninja -C out/release ninja: Entering directory `out/release' [1/1] Regenerating ninja files [511/511] LINK ./crashpad_minidump_test ninja -C out/release 606.80s user 34.71s system 701% cpu 1:31.41 total This differs from the previous attempt, e64cd3aeff71 (https://chromium-review.googlesource.com/c/2288417) in that the arm64 version was built with Xcode 12.2b1 (12B5018i). The linker in this version of Xcode produces linker-signed output for arm64 by default. As of macOS 11.0db6 (20A5364e), all arm64 code must be signed. More information at https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11-universal-apps-beta-release-notes#Code-Signing. In the previous attempt, an older Xcode was used and the output was not signed at all. Because it did not run on systems upgraded to 11.0db6, this version of ninja-mac was backed out in a070dd18d79d (https://chromium-review.googlesource.com/c/2393775). To create this ninja-mac: % git clone https://github.com/ninja-build/ninja.git % cd ninja % git checkout v1.8.2 % mkdir ../build % cd ../build % LDFLAGS=-Wl,-s ../ninja/configure.py --bootstrap % lipo -create -output ninja-mac $(which ninja-mac) ninja An explanation of the LDFLAGS: e64cd3aeff71 used “strip” on the output, matching the stripped x86_64 slice, but “strip” is not currently compatible with linker-signed executables. This is documented at https://developer.apple.com/documentation/xcode-release-notes/xcode-12_2-beta-release-notes#Apple-Clang-Compiler. I was unable to use the recommended workaround in this case. Rather than leave the output unstripped, I asked ld64 to strip symbols using its -s option, which it believes is obsolete, but in fact provides the intended behavior. The x86_64 slice is unsigned, as it was previously. The new arm64 slice is linker-signed with an ad-hoc signature. The x86_64 slice was built with the macOS 10.12 SDK and runs on Mac OS X 10.6 or later. The arm64 slice was built with and has a minimum runtime requirement of macOS 11.0. In practice, the difference doesn’t matter, as the 11.0 SDK is required to build for arm64, and no macOS version earlier than 11.0 will run on arm64. Bug: chromium:1103315 Change-Id: I9f201d0d6f476e187acc0008681c3fd2c1a72aa0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/2427051 Reviewed-by: Nico Weber <thakis@chromium.org> Commit-Queue: Mark Mentovai <mark@chromium.org>
Tools for working with Chromium development. It requires python 2.7 or 3.8 for python 3 support.
The most important tools are:
fetch
: A gclient
wrapper to checkout a project. Use fetch --help
for more details.gclient
: A meta-checkout tool. Think repo or git submodules, except that it support OS-specific rules, e.g. do not checkout Windows only dependencies when checking out for Android. Use gclient help
for more details and README.gclient.md.git cl
: A code review tool to interact with Rietveld or Gerrit. Use git cl help
for more details and README.git-cl.md.roll-dep
: A gclient dependency management tool to submit a dep roll, updating a dependency to a newer revision.There are a lot of git utilities included.
depot_tools
updates itself automatically when running gclient
tool. To disable auto update, set the environment variable DEPOT_TOOLS_UPDATE=0
.
To update package manually, run update_depot_tools.bat
on Windows, or ./update_depot_tools
on Linux or Mac.
On Windows only, running gclient
will install git
and python
.
To contribute change for review:
git new-branch <somename> # Hack git add . git commit -a -m "Fixes goat teleporting" # find reviewers git cl owners git log -- <yourfiles> # Request a review. git cl upload -r reviewer1@chromium.org,reviewer2@chromium.org --send-mail # Edit change description if needed. git cl desc # If change is approved, flag it to be committed. git cl set-commit # If change needs more work. git rebase-update ... git cl upload -t "Fixes goat teleporter destination to be Australia"
See also open bugs, open reviews, forum or report problems.
Until 2018, our cpplint.py
was a copy of the upstream version at https://github.com/google/styleguide/tree/gh-pages/cpplint. Unfortunately, that repository is not maintained any more. If you want to update cpplint.py
in depot_tools
, just upload a patch to do so. We will figure out a long-term strategy via issue https://crbug.com/916550.
Note that the cpplint.py
here is also used by the Tricium analyzer, so if the cpplint.py here changes, we should also update the copy used there.