Fix spelling mistakes in //docs.
This includes spelling mistakes like: accomodate->accommodate ommited->omitted unuseable->unusable dependant->dependent enviroment->environment preceed->precede occurrance->occurrence occurrances->occurrences intergrated->integrated altough->although appriopriate->appropriate corresponing->corresponding dependecies->dependencies leniant->lenient overriden->overridden persisten->persistent specifyinhg->specifying As well as capitalization changes like: javascript->JavaScript Webkit->WebKit linux->Linux A couple other minor things: the the -> the trybot -> try bot etc. Review-Url: https://codereview.chromium.org/2551513002 Cr-Commit-Position: refs/heads/master@{#436046}
This commit is contained in:
qyearsley
docs
android_accessing_cpp_enums_in_java.mdandroid_studio.mdangle_in_chromium.mdaudio_focus.mdbrowser_view_resizer.mdchrome_settings.mdclang_tool_refactoring.mdclosure_compilation.mdcr_user_manual.mddocumentation_best_practices.mdemacs.mdgit_cookbook.mdhow_to_extend_layout_test_framework.mdipc_fuzzer.mdlinux_chromium_arm.mdlinux_debugging.mdlinux_eclipse_dev.mdlinux_gtk_theme_integration.mdlinux_profiling.mdlinux_sandboxing.mdlinux_sublime_dev.mdlinux_sysroot.md
memory-infra
optional.mdprofiling_content_shell_on_android.mdproxy_auto_config.mdupdating_clang.mdupdating_clang_format_binaries.mduseful_urls.mdvanilla_msysgit_workflow.mdworking_remotely_with_android.md@ -20,7 +20,7 @@ directive (optional)
|
||||
the `GENERATED_JAVA_PREFIX_TO_STRIP` directive (optional)
|
||||
* Supports
|
||||
[`@IntDef`](https://developer.android.com/reference/android/support/annotation/IntDef.html)
|
||||
* Copies comments that directly preceed enum entries into the generated Java
|
||||
* Copies comments that directly precede enum entries into the generated Java
|
||||
class
|
||||
|
||||
## Usage
|
||||
|
||||
@ -47,7 +47,7 @@ Gradle sub-project.
|
||||
|
||||
Gradle supports source directories but not source files. However, some
|
||||
`java/src/` directories in Chromium are split amonst multiple GN targets. To
|
||||
accomodate this, the script detects such targets and creates a `symlinked-java/`
|
||||
accommodate this, the script detects such targets and creates a `symlinked-java/`
|
||||
directory to point gradle at. Be warned that creating new files from Android
|
||||
Studio within these symlink-based projects will cause new files to be created in
|
||||
the generated `symlinked-java/` rather than the source tree where you want it.
|
||||
|
||||
@ -32,7 +32,7 @@ ninja -C out\Release libEGL.dll
|
||||
|
||||
Change files then commit locally.
|
||||
|
||||
Upload to gerrit for review. You will need to have installed the git hook as
|
||||
Upload to Gerrit for review. You will need to have installed the git hook as
|
||||
described in the "Getting started with Gerrit for ANGLE" section of the
|
||||
ContributingCode doc before committing them locally.
|
||||
|
||||
@ -40,10 +40,10 @@ ContributingCode doc before committing them locally.
|
||||
git cl upload
|
||||
```
|
||||
|
||||
As with subversion and rietveld: visit the upload link for the review site,
|
||||
As with subversion and Rietveld: visit the upload link for the review site,
|
||||
check the diff and the commit message then add reviewer(s) and publish.
|
||||
|
||||
Land your changes to the upstream repository from the gerrit web interface.
|
||||
Land your changes to the upstream repository from the Gerrit web interface.
|
||||
|
||||
If there are upstream changes, you may need to rebase your patches and reupload
|
||||
them.
|
||||
|
||||
@ -73,7 +73,7 @@ The algorithm is as follows:
|
||||
* If the next top entry is transient, do nothing, since if there is any
|
||||
persistent session that is active, it is already ducking.
|
||||
* If the next top entry is persistent, let the next top entry start ducking,
|
||||
since it is the only active persisten session.
|
||||
since it is the only active persistent session.
|
||||
|
||||
* When a `MediaSession` abandons audio focus:
|
||||
|
||||
|
||||
@ -92,7 +92,7 @@ resizing arrows when the mouse hovers over the resize widget area.
|
||||
|
||||
To make sure that the scroll bars (handled by `WebKit`) are not drawn on top of
|
||||
the resizer widget (or vice versa), we need to properly implement the callback
|
||||
specifyinhg the rectangle covered by the resizer. This callback is implemented
|
||||
specifying the rectangle covered by the resizer. This callback is implemented
|
||||
on the `RenderWidget` class that can delegate to a derive class via a new
|
||||
virtual method which returns an empty rect on the base class. Via a series of
|
||||
delegate interface calls, we eventually get back to the browser view which can
|
||||
|
||||
@ -78,7 +78,7 @@ For simple prefs, the UI is kept in sync with the value automagically (see
|
||||
`CoreOptionsHandler`). Find the handler most closely relevant to your pref. The
|
||||
only action we need take here is to make the page aware of the new string.
|
||||
Locate the method in the handler called `GetLocalizedStrings` and look at its
|
||||
body for examples of `SetString` usage. The first parameter is the javascript
|
||||
body for examples of `SetString` usage. The first parameter is the JavaScript
|
||||
name for the string.
|
||||
|
||||
### 4. HTML/CSS/JS
|
||||
|
||||
@ -113,7 +113,7 @@ It is important to use --bootstrap as there appear to be [bugs](https://crbug.co
|
||||
in the clang library this script produces if you build it with gcc, which is the default.
|
||||
|
||||
## Running
|
||||
First, build all chromium targets to avoid failures due to missing dependecies
|
||||
First, build all Chromium targets to avoid failures due to missing dependencies
|
||||
that are generated as part of the build:
|
||||
|
||||
```shell
|
||||
|
||||
@ -44,7 +44,7 @@ tags](https://developers.google.com/closure/compiler/docs/js-for-compiler)
|
||||
```js
|
||||
/**
|
||||
* @param {string} version A software version number (i.e. "50.0.2661.94").
|
||||
* @return {!Array<number>} Numbers corresponing to |version| (i.e. [50, 0, 2661, 94]).
|
||||
* @return {!Array<number>} Numbers corresponding to |version| (i.e. [50, 0, 2661, 94]).
|
||||
*/
|
||||
function versionSplit(version) {
|
||||
return version.split('.').map(Number);
|
||||
|
||||
@ -5,7 +5,7 @@ behind an abstraction layer. Nothing that cr does can't be done manually, but cr
|
||||
attempts to make things nicer. Its main additional feature is that it allows you
|
||||
to build many configurations and run targets within a single checkout (by not
|
||||
relying on a directory called 'out'). This is especially important when you want
|
||||
to cross-compile (for instance, building android from linux or building arm from
|
||||
to cross-compile (for instance, building Android from Linux or building arm from
|
||||
intel), but it extends to any build variation.
|
||||
|
||||
[TOC]
|
||||
@ -52,7 +52,7 @@ will list all the commands installed
|
||||
|
||||
will give you more detailed help for a specific command.
|
||||
|
||||
_**A note to existing android developers:**_
|
||||
_**A note to existing Android developers:**_
|
||||
|
||||
* Do not source envsetup! ever!
|
||||
* If you use cr in a shell that has had envsetup sourced, miscellaneous things
|
||||
@ -93,7 +93,7 @@ Build a target.
|
||||
install
|
||||
|
||||
Install a binary. Does build first unless `--builder==skip`. This does nothing
|
||||
on linux, and installs the apk onto the device for android builds.
|
||||
on Linux, and installs the apk onto the device for Android builds.
|
||||
|
||||
run
|
||||
|
||||
@ -116,7 +116,7 @@ Run an exernal command in a cr environment. This is an escape hatch, if passed
|
||||
a command it runs it in the correct environment for the current output
|
||||
directory, otherwise it starts a sub shell with that environment. This allows
|
||||
you to run any commands that don't have shims, or are too specialized to get
|
||||
one. This is especially important on android where the environment is heavily
|
||||
one. This is especially important on Android where the environment is heavily
|
||||
modified.
|
||||
|
||||
## Preparing to build
|
||||
@ -126,8 +126,8 @@ You do this with:
|
||||
|
||||
cr init
|
||||
|
||||
By default on linux this will prepare a linux x86 release build output
|
||||
directory, called `out_linux/Release`, if you want an android debug one, you can
|
||||
By default on Linux this will prepare a Linux x86 release build output
|
||||
directory, called `out_linux/Release`, if you want an Android debug one, you can
|
||||
use:
|
||||
|
||||
cr init --out=out_android/Debug
|
||||
@ -136,7 +136,7 @@ The output directory can be called anything you like, but if you pick a non
|
||||
standard name cr might not be able to infer the platform, in which case you need
|
||||
to specify it. The second part **must** be either Release or Debug. All options
|
||||
can be shortened to the shortest non ambiguous prefix, so the short command line
|
||||
to prepare an android debug output directory in out is:
|
||||
to prepare an Android debug output directory in out is:
|
||||
|
||||
cr init --o=out/Debug --p=android
|
||||
|
||||
@ -209,7 +209,7 @@ query, but here are the high level issues:
|
||||
to infer from the target whether it is a runnable binary or a test. The
|
||||
inference could be improved, and it needs to handle the other test types as
|
||||
well.
|
||||
* **No support for windows or mac** : allowed for in the design, but need
|
||||
* **No support for Windows or Mac** : allowed for in the design, but need
|
||||
people with expertise on those platforms to help out
|
||||
* **Bash completion** : The hooks for it are there, but at the moment it only
|
||||
ever completes the command, not any of the arguments
|
||||
|
||||
@ -110,6 +110,6 @@ keep it in shared Drive folders.
|
||||
|
||||
Do not write your own guide to a common technology or process. Link to it
|
||||
instead. If the guide doesn't exist or it's badly out of date, submit your
|
||||
updates to the appriopriate docs/ directory or create a package-level
|
||||
updates to the appropriate docs/ directory or create a package-level
|
||||
README.md. **Take ownership and don't be shy**: Other teams will usually welcome
|
||||
your contributions.
|
||||
|
||||
@ -61,7 +61,7 @@ file:
|
||||
```el
|
||||
;; For dealing with WebKit long lines and word wrapping.
|
||||
(defun c-mode-adaptive-indent (beg end)
|
||||
"Set the wrap-prefix for the the region between BEG and END with adaptive filling."
|
||||
"Set the wrap-prefix for the region between BEG and END with adaptive filling."
|
||||
(goto-char beg)
|
||||
(while
|
||||
(let ((lbp (line-beginning-position))
|
||||
|
||||
@ -9,7 +9,7 @@ See also [Git Tips](git_tips.md).
|
||||
## Introduction
|
||||
|
||||
This is designed to be a cookbook for common command sequences/tasks relating to
|
||||
git, git-cl, and how they work with chromium development. It might be a little
|
||||
git, git-cl, and how they work with Chromium development. It might be a little
|
||||
light on explanations.
|
||||
|
||||
If you are new to git, or do not have much experience with a distributed version
|
||||
@ -152,7 +152,7 @@ git cl issue 12345 # restore the rietveld issue that was cleared on commit
|
||||
```
|
||||
|
||||
And now you can continue hacking where you left off, and since you're reusing
|
||||
the Reitveld issue you don't have to rewrite the commit message. (You may want
|
||||
the Rietveld issue you don't have to rewrite the commit message. (You may want
|
||||
to go manually reopen the issue on the Rietveld site -- `git cl status` will
|
||||
give you the URL.)
|
||||
|
||||
@ -178,7 +178,7 @@ understands relative paths.
|
||||
|
||||
## Checking out pristine branch from git-svn
|
||||
|
||||
In the backend, git-svn keeps a remote tracking branch that points to the the
|
||||
In the backend, git-svn keeps a remote tracking branch that points to the
|
||||
commit tree representing the svn repository. The name of this branch is
|
||||
configured during `git svn init`. The git-svn remote branch is often named
|
||||
`origin/trunk` for Chromium, and `origin/master` for WebKit.
|
||||
|
||||
@ -19,11 +19,11 @@ with how to use it. See the
|
||||
|
||||
There are two parts to actually extending framework to test a piece of software.
|
||||
The first part is extending certain files in:
|
||||
[/third_party/Webkit/Tools/Scripts/webkitpy/layout_tests/](/third_party/Webkit/Tools/Scripts/webkitpy/layout_tests/)
|
||||
[/third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/](/third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/)
|
||||
The code in `webkitpy/layout_tests` is the layout test framework itself
|
||||
|
||||
The second part is creating a driver (program) to actually communicate the
|
||||
layout test framework. This part is significantly more tricky and dependant on
|
||||
layout test framework. This part is significantly more tricky and dependent on
|
||||
what exactly exactly is being tested.
|
||||
|
||||
### Part 1
|
||||
@ -109,7 +109,7 @@ and MacPort (and maybe the android port class) should be extended as they
|
||||
provide platform specific overrides/extensions that implement most of the
|
||||
important functionality. While there are many functions in Port, overriding one
|
||||
function will affect most of the other ones to get the desired behavior. For
|
||||
example, if `layout_tests_dir()` is overriden, not only will the code look for
|
||||
example, if `layout_tests_dir()` is overridden, not only will the code look for
|
||||
tests in that directory, but it will find the correct TestExpectations file, the
|
||||
platform specific expected files, etc.
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# IPC Fuzzer
|
||||
|
||||
A chromium IPC fuzzer is under development by aedla and tsepez. The fuzzer lives
|
||||
A Chromium IPC fuzzer is under development by aedla and tsepez. The fuzzer lives
|
||||
under `src/tools/ipc_fuzzer/` and is running on ClusterFuzz. A previous version
|
||||
of the fuzzer was a simple bitflipper, which caught around 10 bugs. A new
|
||||
version is doing smarter mutations and generational fuzzing. To do so, each
|
||||
|
||||
@ -44,7 +44,7 @@ gn args:
|
||||
|
||||
Chromium's testing infrastructure for ARM/Linux is somewhat limited.
|
||||
There are currently two builders setup, one on the FYI waterfall and one
|
||||
the the trybot waterfall:
|
||||
the the try bot waterfall:
|
||||
|
||||
* [Linux ARM](http://build.chromium.org/p/chromium.fyi/builders/Linux%20ARM)
|
||||
* [linux_arm](http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_arm)
|
||||
|
||||
@ -375,15 +375,15 @@ for discussion of a simpler way.)
|
||||
|
||||
BROWSER_WRAPPER='xterm -e gdb --args' out/Debug/browser_tests
|
||||
|
||||
### Replicating Trybot Slowness
|
||||
### Replicating try bot Slowness
|
||||
|
||||
Trybots are pretty stressed, and can sometimes expose timing issues you can't
|
||||
Try bots are pretty stressed, and can sometimes expose timing issues you can't
|
||||
normally reproduce locally.
|
||||
|
||||
You can simulate this by shutting down all but one of the CPUs
|
||||
(http://www.cyberciti.biz/faq/debian-rhel-centos-redhat-suse-hotplug-cpu/) and
|
||||
running a CPU loading tool (e.g., http://www.devin.com/lookbusy/). Now run your
|
||||
test. It will run slowly, but any flakiness found by the trybot should replicate
|
||||
test. It will run slowly, but any flakiness found by the try bot should replicate
|
||||
locally now - and often nearly 100% of the time.
|
||||
|
||||
## Logging
|
||||
@ -393,7 +393,7 @@ locally now - and often nearly 100% of the time.
|
||||
Default log level hides `LOG(INFO)`. Run with `--log-level=0` and
|
||||
`--enable-logging=stderr` flags.
|
||||
|
||||
Newer versions of chromium with VLOG may need --v=1 too. For more VLOG tips, see
|
||||
Newer versions of Chromium with VLOG may need --v=1 too. For more VLOG tips, see
|
||||
[the chromium-dev thread](http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/dcd0cd7752b35de6?pli=1).
|
||||
|
||||
### Seeing IPC debug messages
|
||||
|
||||
@ -294,7 +294,7 @@ best for me.
|
||||
1. This creates a single list of include directories and preprocessor
|
||||
definitions to be used for all source files, and so is a little
|
||||
inaccurate. Here are some tips for compensating for the limitations:
|
||||
1. If you care about blink, move 'third\_party/Webkit/Source' to the
|
||||
1. If you care about blink, move 'third\_party/WebKit/Source' to the
|
||||
top of the list to better resolve ambiguous include paths (eg.
|
||||
`config.h`).
|
||||
1. Import paths and symbols
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# Linux GTK Theme Integration
|
||||
Linux GTK Theme Integration
|
||||
|
||||
The GTK+ port of Chromium has a mode where we try to match the user's GTK theme
|
||||
(which can be enabled under Wrench -> Options -> Personal Stuff -> Set to GTK+
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Linux Profiling
|
||||
|
||||
How to profile chromium on Linux.
|
||||
How to profile Chromium on Linux.
|
||||
|
||||
See
|
||||
[Profiling Chromium and WebKit](https://sites.google.com/a/chromium.org/dev/developers/profiling-chromium-and-webkit)
|
||||
@ -172,7 +172,7 @@ executables well).
|
||||
First, you will need to build massif from valgrind-variant project yourself,
|
||||
it's [easy](http://code.google.com/p/valgrind-variant/wiki/HowTo).
|
||||
|
||||
Then, make sure your chromium is built using the
|
||||
Then, make sure your Chromium is built using the
|
||||
[valgrind instructions](http://www.chromium.org/developers/how-tos/using-valgrind).
|
||||
Now, you can run massif like this:
|
||||
|
||||
|
||||
@ -46,7 +46,7 @@ network, something that is difficult to perform at the layer-2.
|
||||
| [Seccomp-BPF](#The_seccomp-bpf_sandbox.md) | Layer-2 in some Zygote processes (renderers, PPAPI, [NaCl](http://www.chromium.org/nativeclient)), Layer-1 + Layer-2 in GPU process | Linux kernel >= 3.5, Chrome OS and Ubuntu | Enabled by default and actively developed |
|
||||
| [Seccomp-legacy](#The_seccomp_sandbox.md) | Layer-2 in renderers | All | [Deprecated](https://src.chromium.org/viewvc/chrome?revision=197301&view=revision) |
|
||||
| [SELinux](#SELinux.md) | Layer-1 in Zygote processes (renderers, PPAPI) | SELinux distributions | [Deprecated](https://src.chromium.org/viewvc/chrome?revision=200838&view=revision) |
|
||||
| Apparmor | Outer layer-1 in Zygote processes (renderers, PPAPI) | Not used | Deprecated |
|
||||
| AppArmor | Outer layer-1 in Zygote processes (renderers, PPAPI) | Not used | Deprecated |
|
||||
|
||||
## The setuid sandbox
|
||||
|
||||
|
||||
@ -96,10 +96,10 @@ The settings will take effect as soon as you save the file.
|
||||
* `Alt + PageUp`/`Alt + PageDown` (`Alt + Cmd + Left`/`Alt + Cmd + Right` on
|
||||
Mac) moves between tabs
|
||||
* `F12` (`Alt + Cmd + Down` on Mac) goes to the symbol's definition
|
||||
* With text selected, `Ctrl + D` will multi-select the next occurrance (so
|
||||
* With text selected, `Ctrl + D` will multi-select the next occurrence (so
|
||||
typing in one types in all of them), and `Ctrl+U` deselects
|
||||
* Similarly, after finding something with `Ctrl + F`, `Alt + Enter` will
|
||||
select all occurrances of the search query, which can be multi-edited
|
||||
select all occurrences of the search query, which can be multi-edited
|
||||
* `Ctrl + X` without anything selected cuts the current line, then move to a
|
||||
different line and `Ctrl + V` pastes it below the current line
|
||||
|
||||
|
||||
@ -22,7 +22,7 @@ hooks. When run from hooks this script in a no-op on non-linux platforms.
|
||||
## Rebuilding the sysroot image
|
||||
|
||||
The pre-built sysroot images occasionally needs to be rebuilt. For example,
|
||||
when security updates to debian are released, or when a new package is needed by
|
||||
when security updates to Debian are released, or when a new package is needed by
|
||||
the chromium build.
|
||||
|
||||
### Rebuilding
|
||||
|
||||
@ -69,7 +69,7 @@ process. This is what exerts memory pressure on the system.
|
||||
* **Swapped**: The total size of anonymous memory used by process, which is
|
||||
swapped out of RAM.
|
||||
|
||||
**Columns in black** reflect a best estimation of the the amount of physical
|
||||
**Columns in black** reflect a best estimation of the amount of physical
|
||||
memory used by various subsystems of Chrome.
|
||||
|
||||
* **Blink GC**: Memory used by [Oilpan][oilpan].
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
As of Chrome 48, MemoryInfra supports heap profiling. The core principle is
|
||||
a solution that JustWorks™ on all platforms without patching or rebuilding,
|
||||
intergrated with the chrome://tracing ecosystem.
|
||||
integrated with the chrome://tracing ecosystem.
|
||||
|
||||
[TOC]
|
||||
|
||||
@ -121,7 +121,7 @@ size concerns. Development builds have full type information.
|
||||
|
||||
To keep the trace log small, uninteresting information is omitted from heap
|
||||
dumps. The long tail of small nodes is not dumped, but grouped in an `<other>`
|
||||
node instead. Note that altough these small nodes are insignificant on their
|
||||
node instead. Note that although these small nodes are insignificant on their
|
||||
own, together they can be responsible for a significant portion of the heap. The
|
||||
`<other>` node is large in that case.
|
||||
|
||||
|
||||
@ -101,7 +101,7 @@ undefined value when the expected value can't be negative.
|
||||
|
||||
It is recommended to not use `base::Optional<T>` as a function parameter as it
|
||||
will force the callers to use `base::Optional<T>`. Instead, it is recommended to
|
||||
keep using `T*` for arguments that can be ommited, with `nullptr` representing
|
||||
keep using `T*` for arguments that can be omitted, with `nullptr` representing
|
||||
no value.
|
||||
|
||||
Furthermore, depending on `T`, MSVC might fail to compile code using
|
||||
|
||||
@ -17,7 +17,7 @@ don’t mind erasing all data, rooting, and installing a userdebug build on.
|
||||
[Android Build Instructions](android_build_instructions.md).)
|
||||
|
||||
1. Get the code! You’ll want a second checkout as this will be
|
||||
android-specific. You know the drill:
|
||||
Android-specific. You know the drill:
|
||||
https://www.chromium.org/developers/how-tos/get-the-code
|
||||
1. Append this to your `.gclient` file: `target_os = ['android']`
|
||||
1. Create `chromium.gyp_env` next to your `.gclient` file:
|
||||
@ -112,7 +112,7 @@ Telemetry" steps below).
|
||||
|
||||
## Install `/system/bin/perf` on your device (not needed for Telemetry)
|
||||
|
||||
# From inside the android source tree (not inside Chromium)
|
||||
# From inside the Android source tree (not inside Chromium)
|
||||
mmm external/linux-tools-perf/
|
||||
adb remount # (allows you to write to the system image)
|
||||
adb sync
|
||||
|
||||
@ -12,7 +12,7 @@ Currently, WPAD is pretty slow when we're starting up Chrome - we have to query
|
||||
the local network for WPAD servers using DNS (and maybe NetBIOS), and we wait
|
||||
all the way until the resolver timeout before we try sending any HTTP requests
|
||||
if there's no WPAD server. This is a really crappy user experience, since the
|
||||
browser's basically unuseable for a couple of seconds after startup if
|
||||
browser's basically unusable for a couple of seconds after startup if
|
||||
autoconfig is turned on and there's no WPAD server.
|
||||
|
||||
## Solution
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
changes
|
||||
1. Run `python tools/clang/scripts/upload_revision.py --clang_revision=NNNN`
|
||||
with the target LLVM SVN revision number
|
||||
1. If the clang upload trybots succeed, run the goma package update script to
|
||||
1. If the clang upload try bots succeed, run the goma package update script to
|
||||
push these packages to goma. If you do not have the necessary credentials to
|
||||
do the upload, ask clang@chromium.org to find someone who does
|
||||
1. Run an exhaustive set of try jobs to test the new compiler:
|
||||
|
||||
@ -19,7 +19,7 @@ consistent state.
|
||||
|
||||
## Build a release-mode clang-format on each platform
|
||||
|
||||
Follow the the official instructions here:
|
||||
Follow the official instructions here:
|
||||
http://clang.llvm.org/get_started.html.
|
||||
|
||||
Windows step-by-step:
|
||||
|
||||
@ -6,10 +6,10 @@ This page aims to be a repository of useful links that people may find useful.
|
||||
## Build Status
|
||||
|
||||
* [Main buildbot waterfall](http://build.chromium.org/p/chromium/console)
|
||||
* [Last Known Good Revision](http://chromium-status.appspot.com/lkgr) : Trybots pull this revision from trunk
|
||||
* [Last Known Good Revision](http://chromium-status.appspot.com/lkgr) : Try bots pull this revision from trunk
|
||||
* [List of the last 100 potential LKGRs](http://chromium-status.appspot.com/revisions)
|
||||
* [Status dashboard for LKGR](http://build.chromium.org/p/chromium/lkgr-status/)
|
||||
* http://build.chromium.org/p/tryserver.chromium/waterfall?committer=developer@chromium.org : Trybot runs, by developer
|
||||
* http://build.chromium.org/p/tryserver.chromium/waterfall?committer=developer@chromium.org : Try bot runs, by developer
|
||||
* [Tree uptime stats](http://chromium-status.appspot.com/status_viewer)
|
||||
* [Commit queue status](http://chromium-cq-status.appspot.com)
|
||||
* [Pending commit queue jobs](http://codereview.chromium.org/search?closed=3&commit=2&limit=50)
|
||||
@ -32,10 +32,10 @@ This page aims to be a repository of useful links that people may find useful.
|
||||
## Source Information
|
||||
|
||||
* [Code Search](http://cs.chromium.org/)
|
||||
* http://cs.chromium.org/SEARCH_TERM : Code Search for a specific SEARCH\_TERM
|
||||
* http://cs.chromium.org/SEARCH_TERM : Code Search for a specific SEARCH\_TERM
|
||||
* [Gitiles Source Code Browser](https://chromium.googlesource.com/chromium/src/)
|
||||
* https://chromium.googlesource.com/chromium/src/+log/b6cfa6a..9a2e0a8?pretty=fuller : Git changes in revision range(also works for build numbers)
|
||||
* http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/trunk/src&mode=html&range=SUCCESS_REV:FAILURE_REV : SVN changes in revision range
|
||||
* http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/trunk/src&mode=html&range=SUCCESS_REV:FAILURE_REV : SVN changes in revision range
|
||||
* http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog_blink.html?url=/trunk&mode=html&range=SUCCESS_REV:FAILURE_REV : Blink changes in revision range
|
||||
|
||||
## Communication
|
||||
|
||||
@ -98,7 +98,7 @@ Pipelining:
|
||||
(to rename)
|
||||
1. Later, when you want to commit one of the earlier changes in the pipeline;
|
||||
all on Linux. The reason you may want to create the separate tip-of-tree
|
||||
branch is in case the trybots show your change failing on tip-of-tree and
|
||||
branch is in case the try bots show your change failing on tip-of-tree and
|
||||
you need to do significant additional work, this avoids having to roll back
|
||||
the tip-of-tree merge:
|
||||
|
||||
|
||||
@ -6,12 +6,12 @@
|
||||
## Introduction
|
||||
|
||||
When you call /build/android/run_tests.py or
|
||||
/build/android/run_instrumentation_tests.py it assumes an android device
|
||||
/build/android/run_instrumentation_tests.py it assumes an Android device
|
||||
is attached to the local host.
|
||||
|
||||
TODO: these scripts do not exist.
|
||||
|
||||
If you want to work remotely from your laptop with an android device attached to
|
||||
If you want to work remotely from your laptop with an Android device attached to
|
||||
it, while keeping an ssh connection to a remote desktop machine where you have
|
||||
your build environment setup, you will have to use one of the two alternatives
|
||||
listed below.
|
||||
@ -33,7 +33,7 @@ See also
|
||||
|
||||
### On your laptop
|
||||
|
||||
You have to have an android device attached to it.
|
||||
You have to have an Android device attached to it.
|
||||
|
||||
```shell
|
||||
# Install sshfs
|
||||
@ -45,7 +45,7 @@ laptop$ sudo apt-get install sshfs
|
||||
laptop$ mkdir ~/chrome_sshfs
|
||||
laptop$ sshfs your.host.machine:/usr/local/code/chrome/src ./chrome_sshfs
|
||||
|
||||
# Setup enviroment.
|
||||
# Setup environment.
|
||||
|
||||
laptop$ cd chrome_sshfs
|
||||
laptop$ . build/android/envsetup.sh
|
||||
@ -66,7 +66,7 @@ This is assuming you have the exact same linux version on your host machine and
|
||||
in your laptop.
|
||||
***
|
||||
|
||||
But if you have different versions, lets say, ubuntu lucid on your laptop, and the newer ubuntu precise on your host machine, some binaries compiled on the host will not work on your laptop.
|
||||
But if you have different versions, lets say, Ubuntu Lucid on your laptop, and the newer Ubuntu Precise on your host machine, some binaries compiled on the host will not work on your laptop.
|
||||
In this case you will have to recompile these binaries in your laptop:
|
||||
|
||||
```shell
|
||||
|
||||
Reference in New Issue
Block a user