libchromiumcontent

Automatically builds and provides prebuilt binaries of the Chromium Content module and all its dependencies (e.g., Blink, V8, etc.).

Development

Prerequisites

• Linux
• Mac
• Windows

Note: Even though it is not mentioned in chromium documentation, pywin32 must also be installed for gclient to work properly. Before invoking script/update, download/install the x64 version from: https://sourceforge.net/projects/pywin32/

One-time setup

$ script/bootstrap

Building

$ script/update -t x64
$ script/build -t x64

Updating project files

If you switch to a different Chromium release, or modify files inside the chromiumcontent directory, you should run:

$ script/update

This will regenerate all the project files. Then you can build again.

Building for ARM target

TODO: This section may be out of date, needs review

$ ./script/bootstrap
$ ./script/update -t arm
$ cd vendor/chromium/src
$ ./build/install-build-deps.sh --arm
$ ./chrome/installer/linux/sysroot_scripts/install-debian.wheezy.sysroot.py --arch=arm
$ cd -
$ ./script/build -t arm

Building for ARM64 target

$ ./script/bootstrap
$ ./script/update -t arm64
$ ./script/build -t arm64
$ ./script/create-dist -t arm64

Adding a Patch

The Chromium checkout consists of several repos. Chromium itself is in the src directory, and its dependencies are in subdirectories of src, mostly in src/third_party/*.

Files in the top level of the patches directory only contain patches for the files in src that belong to the Chromium repo itself. Subdirectories like patches/v8 or patches/third_party/skia contain patches for the corresponding subdirectories in src (src/v8 and src/third_party/skia respectively), which are independent repos.

If you need to make changes in two different repos, you must create two patch files. Giving those patch files the same name is a good idea.

Get Chromium in src/ and apply existing patches to it. No need to do this again if it has already been done:

./script/update

Change to the src directory:

cd src

Stage existing changes to make git diff useful:

git add .

Make any code changes you like.

When you're done, pipe the diff into a patch file. The file should be prefixed with a number with leading zeros that is greater than any existing patch index, e.g. 0052 if the last patch in the folder is named 0051-some-other.patch:

git diff > patches/0052-meaningful-name.patch

Releases

There is no formal release process for libchromiumcontent, as release artifacts are created as a byproduct of CI. When a build is successful, its compiled asset is automatically uploaded to S3. These assets are later downloaded as part of Electron's bootstrap script. These files are about 4GB, so the bootstrap task takes a while to run.

Asset URLs have the following format:

`https://s3.amazonaws.com/github-janky-artifacts/libchromiumcontent/${platform}/${commit}/libchromiumcontent.zip`

Builds exist for the following platform/arch pairs:

• linux/arm
• linux/ia32
• linux/x64
• mas/x64 (though osx/mas would be a more accurate name)
• osx/x64
• win/ia32
• win/x64

The Linux machines only build for pushes by GitHub employees, so PRs from third parties have to have their linux builds triggered manually.

Each platform/arch has its own CI task, so it should be made sure that all platform/arch have the CI tasks started and finished. To verify that a given commit has all the necessary build artifacts:

npm i -g electron/libcc-check
libcc-check 7a9d4a1c9c265468dd54005f6c1920b2cc2c8ec3

Setting libchromiumcontent version in Electron

For Electron versions 1.7 and higher, libchromiumcontent is vendored as a git submodule in the Electron repo. To change the version that Electron is using, use git to check out the target branch / SHA:

cd electron/electron/vendor/libchromiumcontent
git checkout some-branch-or-sha

For Electron versions 1.6 and lower, libchromiumcontent is vendored as part of a (now retired) project called brightray. To change the version that Electron is using, change the commit SHA in config.py.