mac: Make build documentation less out-of-date.
BUG= Review-Url: https://codereview.chromium.org/2225903003 Cr-Commit-Position: refs/heads/master@{#410668}
This commit is contained in:
thakis
@ -5,19 +5,14 @@
|
||||
## Prerequisites
|
||||
|
||||
* A Mac running 10.9+.
|
||||
* [Xcode](https://developer.apple.com/xcode) 5+.
|
||||
* [Xcode](https://developer.apple.com/xcode) 7.3+.
|
||||
* [depot\_tools](http://dev.chromium.org/developers/how-tos/depottools).
|
||||
* Xcode Command Line Tools. Run
|
||||
```
|
||||
xcode-select --install
|
||||
```
|
||||
to install them.
|
||||
* The OSX 10.10 SDK. Run
|
||||
```
|
||||
ls `xcode-select -p`/Platforms/MacOSX.platform/Developer/SDKs
|
||||
```
|
||||
to check whether you have it. If you don't have it, you need to get one from
|
||||
an install of Xcode 6, and place it in the above directory.
|
||||
to check whether you have it. Building with the 10.11 SDK works too, but
|
||||
the releases currently use the 10.10 SDK.
|
||||
|
||||
## Getting the code
|
||||
|
||||
@ -34,50 +29,52 @@ drive name, the default "Macintosh HD2" for a second drive has a space.
|
||||
|
||||
## Building
|
||||
|
||||
Chromium on OS X can only be built using the [Ninja](ninja_build.md) tool and
|
||||
Chromium on OS X is built using the [Ninja](ninja_build.md) tool and
|
||||
the [Clang](clang.md) compiler. See both of those pages for further details on
|
||||
how to tune the build.
|
||||
|
||||
Run
|
||||
|
||||
gn gen out/gn
|
||||
|
||||
to generate build files (replace "gn" in "out/gn" with whatever you like), and
|
||||
then run
|
||||
|
||||
ninja -C out/gn chrome
|
||||
|
||||
to build. You can edit out/gn/args.gn to configure the build.
|
||||
|
||||
Before you build, you may want to
|
||||
[install API keys](https://sites.google.com/a/chromium.org/dev/developers/how-tos/api-keys)
|
||||
so that Chrome-integrated Google services work. This step is optional if you
|
||||
aren't testing those features.
|
||||
|
||||
### Raising system-wide and per-user process limits
|
||||
|
||||
If you see errors like the following:
|
||||
|
||||
```
|
||||
clang: error: unable to execute command: posix_spawn failed: Resource temporarily unavailable
|
||||
clang: error: clang frontend command failed due to signal (use -v to see invocation)
|
||||
```
|
||||
|
||||
you may be running into too-low limits on the number of concurrent processes
|
||||
allowed on the machine. Check:
|
||||
|
||||
sysctl kern.maxproc
|
||||
sysctl kern.maxprocperuid
|
||||
|
||||
You can increase them with e.g.:
|
||||
|
||||
sudo sysctl -w kern.maxproc=2500
|
||||
sudo sysctl -w kern.maxprocperuid=2500
|
||||
|
||||
But normally this shouldn't be necessary if you're building on 10.7 or higher.
|
||||
If you see this, check if some rogue program spawned hundreds of processes and
|
||||
kill them first.
|
||||
|
||||
## Faster builds
|
||||
|
||||
Full rebuilds are about the same speed in Debug and Release, but linking is a
|
||||
lot faster in Release builds.
|
||||
|
||||
Run
|
||||
Put
|
||||
|
||||
GYP_DEFINES=fastbuild=1 build/gyp_chromium
|
||||
is_debug = false
|
||||
|
||||
to disable debug symbols altogether, this makes both full rebuilds and linking
|
||||
faster (at the cost of not getting symbolized backtraces in gdb).
|
||||
in your args.gn to do a release build.
|
||||
|
||||
Put
|
||||
|
||||
is_component_build = true
|
||||
|
||||
in your args.gn to build many small dylibs instead of a single large executable.
|
||||
This makes incremental builds much faster, at the cost of producing a binary
|
||||
that opens less quickly. Component builds work in both debug and release.
|
||||
|
||||
Put
|
||||
|
||||
symbol_level = 1
|
||||
|
||||
in your args.gn to disable debug symbols altogether. This makes both full
|
||||
rebuilds and linking faster (at the cost of not getting symbolized backtraces
|
||||
in gdb).
|
||||
|
||||
You might also want to [install ccache](ccache_mac.md) to speed up the build.
|
||||
|
||||
@ -85,8 +82,7 @@ You might also want to [install ccache](ccache_mac.md) to speed up the build.
|
||||
|
||||
All build output is located in the `out` directory (in the example above,
|
||||
`~/chromium/src/out`). You can find the applications at
|
||||
`{Debug|Release}/ContentShell.app` and `{Debug|Release}/Chromium.app`, depending
|
||||
on the selected configuration.
|
||||
`gn/Content Shell.app` and `gn/Chromium.app`.
|
||||
|
||||
## Unit Tests
|
||||
|
||||
@ -98,10 +94,10 @@ small subset of these is:
|
||||
* `net_unittests` from `net/net.gyp`
|
||||
* `url_unittests` from `url/url.gyp`
|
||||
|
||||
When these tests are built, you will find them in the `out/{Debug|Release}`
|
||||
When these tests are built, you will find them in the `out/gn`
|
||||
directory. You can run them from the command line:
|
||||
|
||||
~/chromium/src/out/Release/unit_tests
|
||||
~/chromium/src/out/gn/unit_tests
|
||||
|
||||
|
||||
## Coding
|
||||
@ -109,12 +105,9 @@ directory. You can run them from the command line:
|
||||
According to the
|
||||
[Chromium style guide](http://dev.chromium.org/developers/coding-style) code is
|
||||
[not allowed to have whitespace on the ends of lines](https://google.github.io/styleguide/cppguide.html#Horizontal_Whitespace).
|
||||
If you edit in Xcode, know that it loves adding whitespace to the ends of lines
|
||||
which can make editing in Xcode more painful than it should be. The
|
||||
[GTM Xcode Plugin](http://code.google.com/p/google-toolbox-for-mac/downloads/list)
|
||||
adds a preference panel to Xcode that allows you to strip whitespace off of the
|
||||
ends of lines on save. Documentation on how to install it is
|
||||
[here](http://code.google.com/p/google-toolbox-for-mac/wiki/GTMXcodePlugin).
|
||||
|
||||
Run `git cl format` after committing to your local branch and before uploading
|
||||
to clang-format your code.
|
||||
|
||||
## Debugging
|
||||
|
||||
@ -122,7 +115,7 @@ Good debugging tips can be found
|
||||
[here](http://dev.chromium.org/developers/how-tos/debugging-on-os-x). If you
|
||||
would like to debug in a graphical environment, rather than using `lldb` at the
|
||||
command line, that is possible without building in Xcode. See
|
||||
[Debugging in Xcode](http://www.chromium.org/developers/debugging-on-os-x/building-with-ninja-debugging-with-xcode)
|
||||
[Debugging in Xcode](http://www.chromium.org/developers/how-tos/debugging-on-os-x/building-with-ninja-debugging-with-xcode)
|
||||
for information on how.
|
||||
|
||||
## Contributing
|
||||
@ -133,46 +126,25 @@ information about writing code for Chromium and contributing it.
|
||||
|
||||
## Using Xcode-Ninja Hybrid
|
||||
|
||||
While using Xcode is unsupported, GYP supports a hybrid approach of using ninja
|
||||
for building, but Xcode for editing and driving compilation. Xcode can still be
|
||||
slow, but it runs fairly well even **with indexing enabled**.
|
||||
While using Xcode is unsupported, gn supports a hybrid approach of using ninja
|
||||
for building, but Xcode for editing and driving compilation. Xcode is still
|
||||
slow, but it runs fairly well even **with indexing enabled**. Most people
|
||||
build in the Terminal and write code with a text editor though.
|
||||
|
||||
With hybrid builds, compilation is still handled by ninja, and can be run by the
|
||||
command line (e.g. ninja -C out/Debug chrome) or by choosing the chrome target
|
||||
command line (e.g. ninja -C out/gn chrome) or by choosing the chrome target
|
||||
in the hybrid workspace and choosing build.
|
||||
|
||||
To use Xcode-Ninja Hybrid, set GYP\_GENERATORS like the following:
|
||||
To use Xcode-Ninja Hybrid pass --ide=xcode to `gn gen`
|
||||
|
||||
```shell
|
||||
export GYP_GENERATORS="ninja,xcode-ninja"
|
||||
gn gen out/gn --ide=xcode
|
||||
```
|
||||
|
||||
Due to the way Xcode parses ninja output paths, it's also necessary to change
|
||||
the main gyp location to anything two directories deep. Otherwise Xcode build
|
||||
output will not be clickable.
|
||||
To make this change permanent, you can edit `chromium.gyp_env` (or create it if
|
||||
it does not exists) and define GYP\_GENERATOR\_FLAGS. In general, to use hybrid
|
||||
mode, your `chromium.gyp_env` could contain the following:
|
||||
|
||||
```json
|
||||
{
|
||||
"GYP_GENERATORS" : "ninja,xcode-ninja",
|
||||
"GYP_GENERATOR_FLAGS":
|
||||
"xcode_project_version=3.2 " +
|
||||
"xcode_ninja_main_gyp=src/build/ninja/all.ninja.gyp",
|
||||
}
|
||||
```
|
||||
|
||||
After, generate the project files with:
|
||||
Open it:
|
||||
|
||||
```shell
|
||||
gclient runhooks
|
||||
```
|
||||
|
||||
And finally, open it:
|
||||
|
||||
```shell
|
||||
open build/ninja/all.ninja.xcworkspace
|
||||
open out/gn/ninja/all.xcworkspace
|
||||
```
|
||||
|
||||
You may run into a problem where http://YES is opened as a new tab every time
|
||||
@ -182,52 +154,11 @@ Versions Browser". When this option is checked, Xcode adds
|
||||
`--NSDocumentRevisionsDebugMode YES` to the launch arguments, and the `YES` gets
|
||||
interpreted as a URL to open.
|
||||
|
||||
If you want to limit the number of targets visible, which is known to improve
|
||||
Xcode performance, add `xcode_ninja_executable_target_pattern=%target%` where
|
||||
`%target%` is a regular expression matching executable targets you'd like to
|
||||
include.
|
||||
|
||||
To include non-executable targets, use `xcode_ninja_target_pattern=All_iOS`.
|
||||
|
||||
If you have problems building, join us in `#chromium` on `irc.freenode.net` and
|
||||
ask there. As mentioned above, be sure that the
|
||||
[waterfall](http://build.chromium.org/buildbot/waterfall/) is green and the tree
|
||||
is open before checking out. This will increase your chances of success.
|
||||
|
||||
## Using Emacs as `EDITOR` for `git commit`
|
||||
|
||||
Using the [Cocoa version of Emacs](http://emacsformacosx.com/) as the `EDITOR`
|
||||
environment variable on Mac OS will cause `git commit` to open the message in a
|
||||
window underneath all the others. To fix this, create a shell script somewhere
|
||||
(call it `$HOME/bin/EmacsEditor` in this example) containing the following:
|
||||
|
||||
```
|
||||
#!/bin/sh
|
||||
|
||||
# All of these hacks are needed to get "git commit" to launch a new
|
||||
# instance of Emacs on top of everything else, properly pointing to
|
||||
# the COMMIT_EDITMSG.
|
||||
|
||||
realpath() {
|
||||
[[ $1 = /* ]] && echo "$1" || echo "$PWD/${1#./}"
|
||||
}
|
||||
|
||||
i=0
|
||||
full_paths=()
|
||||
for arg in "$@"
|
||||
do
|
||||
full_paths[$i]=$(realpath $arg)
|
||||
((++i))
|
||||
done
|
||||
|
||||
open -nWa /Applications/Emacs.app/Contents/MacOS/Emacs --args --no-desktop \
|
||||
"${full_paths[@]}"
|
||||
```
|
||||
|
||||
and in your `.bashrc` or similar,
|
||||
|
||||
export EDITOR=$HOME/bin/EmacsEditor
|
||||
|
||||
## Improving performance of `git status`
|
||||
|
||||
`git status` is used frequently to determine the status of your checkout. Due
|
||||
|
||||
Reference in New Issue
Block a user