| Alex Crichton | d9962f4 | 2015-09-17 17:45:10 -0700 | [diff] [blame] | 1 | The goal of the libc crate is to have CI running everywhere to have the |
| 2 | strongest guarantees about the definitions that this library contains, and as a |
| 3 | result the CI is pretty complicated and also pretty large! Hopefully this can |
| 4 | serve as a guide through the sea of scripts in this directory and elsewhere in |
| 5 | this project. |
| 6 | |
| Alex Crichton | 145ac09 | 2015-09-17 17:52:13 -0700 | [diff] [blame^] | 7 | # Files |
| 8 | |
| Alex Crichton | d9962f4 | 2015-09-17 17:45:10 -0700 | [diff] [blame] | 9 | First up, let's talk about the files in this directory: |
| 10 | |
| 11 | * `Dockerfile-android`, `android-accept-licenses.sh` -- these two files are |
| 12 | used to build the Docker image that the android CI builder uses. The |
| 13 | `Dockerfile` just installs the Android SDK, NDK, a Rust nightly, Rust target |
| 14 | libraries for Android, and sets up an emulator to run tests in. You can build |
| 15 | a new image with this command (from the root of the project): |
| 16 | |
| 17 | docker build -t alexcrichton/rust-libc-test -f ci/Dockerfile-android . |
| 18 | |
| 19 | When building a new image contact @alexcrichton to push it to the docker hub |
| 20 | and have libc start using it. This hasn't needed to happen yet, so the process |
| 21 | may be a little involved. |
| 22 | |
| 23 | The script here, `android-accept-licenses.sh` is just a helper used to accept |
| 24 | the licenses of the SDK of Android while the docker image is being created. |
| 25 | |
| 26 | * `msys2.ps1` - a PowerShell script which is used to install MSYS2 on the |
| 27 | AppVeyor bots. As of this writing MSYS2 isn't installed by default, and this |
| 28 | script will install the right version/arch of msys2 in preparation of using |
| 29 | the contained C compiler to compile C shims. |
| 30 | |
| 31 | * `run-travis.sh` - a shell script run by all Travis builders, this is |
| 32 | responsible for setting up the rest of the environment such as installing new |
| 33 | packages, downloading Rust target libraries, etc. |
| 34 | |
| 35 | * `run.sh` - the actual script which runs tests for a particular architecture. |
| 36 | Called from the `run-travis.sh` script this will run all tests for the target |
| 37 | specified. |
| 38 | |
| 39 | * `cargo-config` - Cargo configuration of linkers to use copied into place by |
| 40 | the `run-travis.sh` script before builds are run. |
| 41 | |
| 42 | * `dox.sh` - script called from `run-travis.sh` on only the linux 64-bit nightly |
| 43 | Travis bots to build documentation for this crate. |
| 44 | |
| 45 | * `landing-page-*.html` - used by `dox.sh` to generate a landing page for all |
| 46 | architectures' documentation. |
| 47 | |
| Alex Crichton | 145ac09 | 2015-09-17 17:52:13 -0700 | [diff] [blame^] | 48 | # CI Systems |
| 49 | |
| 50 | Currently this repository leverages a combination of Travis CI and AppVeyor for |
| 51 | running tests. The triples tested are: |
| 52 | |
| 53 | * AppVeyor |
| 54 | * `{i686,x86_64}-pc-windows-{msvc,gnu}` |
| 55 | * Travis |
| 56 | * `{i686,x86_64,mips,aarch64}-unknown-linux-gnu` |
| 57 | * `x86_64-unknown-linux-musl` |
| 58 | * `arm-unknown-linux-gnueabihf` |
| 59 | * `arm-linux-androideabi` |
| 60 | * `{i686,x86_64}-apple-darwin` |
| 61 | |
| 62 | The Windows triples are all pretty standard, they just set up their environment |
| 63 | then run tests, no need for downloading any extra target libs (we just download |
| 64 | the right installer). The Intel Linux/OSX builds are similar in that we just |
| 65 | download the right target libs and run tests. Note that the Intel Linux/OSX |
| 66 | builds are run on stable/beta/nightly, but are the only ones that do so. |
| 67 | |
| 68 | The remaining architectures look like: |
| 69 | |
| 70 | * Android runs in a docker image with an emulator, the NDK, and the SDK already |
| 71 | set up (see `Dockerfile-android`). The entire build happens within the docker |
| 72 | image. |
| 73 | * The MIPS, ARM, and AArch64 builds all use QEMU to run the generated binary to |
| 74 | actually verify the tests pass. |
| 75 | * The MUSL build just has to download a MUSL compiler and target libraries and |
| 76 | then otherwise runs tests normally. |
| 77 | |
| 78 | Hopefully that's at least somewhat of an introduction to everything going on |
| 79 | here, and feel free to ping @alexcrichton with questions! |
| 80 | |