This page describes the structure of source code of the GCC-based Native Client toolchain. The sources are based on stable releases of external packages: Binutils, GCC, Newlib, GDB, GlibC plus a subset of linux kernel headers. The rest of the page addresses the structure of the source repositories, the ways to synchronize patches across them and the build script.
We recommend hacking the toolchain on Linux. After each commit the toolchain tarballs are built on buildbots. Using Windows is difficult since Chromium no longer supports Cygwin, and it's too slow to be practical anyway (mostly due to the poor performance of fork()).
Native Client Source is also required to build the toolchain (specifically, libraries). Follow the instructions on the Native Client Source page to fetch the sources.
If you are going to contribute to the toolchain, you will need to use the Git repository. Add similar lines to your .bashrc or a shell login script:
In the most common case author and committer strings should be equal.
Option 1: Build a newlib-based toolchain
Option 2: Build a GlibC-based toolchain.
The toolchain binaries get installed to native_client/tools/out by default, you bay override it by providing TOOLCHAINLOC=<path> in make invocation.
note: Although the build script is written as a Makefile, it does not support incremental rebuilds (though it supports parallel builds).note: To build in a 100% clean way, the TOOLCHAINLOC directory must be empty.
The Git repositories are hosted at chromium git repositories. NaCl development happens in branch master in each repository.
The branch vendor-src keeps the sources from the original tarball unchanged. From time to time the master branch should be rebased on top of newer revisions of the vendor-src branch. Once the master branch is rebased, the old branch should be kept from garbage collection so that old commits can be found by hashes (required to be able to reproduce old builds).
Follow the Git Cookbook for sending your commit for review. Recommendations: Method #1 is the easiest. Instead of "git cl" you can use git-cl from depot_tools. In the simplest case you may:
Currently it is only easy to run the tests in x86-64 mode, x86-32 testing is broken. To run all tests:
To run one of the three testsuites (c++ testsuite in this case):
To run a subset of a testsuite governed by some '.exp' config file just add the name of the file (without path to it) as additional parameter to runtest:
You may limit running tests to a single file. Again, the file name should omit the path part: