Skip to content
Snippets Groups Projects
Unverified Commit 1ef129b2 authored by Yuki Okushi's avatar Yuki Okushi
Browse files

Minor clean-up CI docs

parent 12c28abe
No related branches found
No related tags found
No related merge requests found
...@@ -4,6 +4,9 @@ result the CI is pretty complicated and also pretty large! Hopefully this can ...@@ -4,6 +4,9 @@ result the CI is pretty complicated and also pretty large! Hopefully this can
serve as a guide through the sea of scripts in this directory and elsewhere in serve as a guide through the sea of scripts in this directory and elsewhere in
this project. this project.
Note that this documentation is quite outdated. See CI config and scripts
in the `ci` directory how we run CI now.
# Files # Files
First up, let's talk about the files in this directory: First up, let's talk about the files in this directory:
...@@ -15,30 +18,10 @@ First up, let's talk about the files in this directory: ...@@ -15,30 +18,10 @@ First up, let's talk about the files in this directory:
* `dox.sh` - build the documentation of the crate and publish it to gh-pages. * `dox.sh` - build the documentation of the crate and publish it to gh-pages.
* `landing-page-*.html` - used by `dox.sh` to generate a landing page for all
architectures' documentation.
* `run-qemu.sh` - see discussion about QEMU below
* `mips`, `rumprun` - instructions to build the docker image for each respective
CI target
# CI Systems # CI Systems
Currently this repository leverages a combination of Travis CI and AppVeyor for Currently this repository leverages a combination of Azure Pipelines and Cirrus CI
running tests. The triples tested are: for running tests. You can find tested triples in [Pipelines config] or [Cirrus config].
* AppVeyor
* `{i686,x86_64}-pc-windows-{msvc,gnu}`
* Travis
* `{i686,x86_64,mips,aarch64}-unknown-linux-gnu`
* `{x86_64,aarch64}-unknown-linux-musl`
* `arm-unknown-linux-gnueabihf`
* `arm-linux-androideabi`
* `{i686,x86_64}-apple-{darwin,ios}`
* `x86_64-rumprun-netbsd`
* `x86_64-unknown-freebsd`
* `x86_64-unknown-openbsd`
The Windows triples are all pretty standard, they just set up their environment The Windows triples are all pretty standard, they just set up their environment
then run tests, no need for downloading any extra target libs (we just download then run tests, no need for downloading any extra target libs (we just download
...@@ -62,7 +45,9 @@ The remaining architectures look like: ...@@ -62,7 +45,9 @@ The remaining architectures look like:
* The BSD builds, currently OpenBSD and FreeBSD, use QEMU to boot up a system * The BSD builds, currently OpenBSD and FreeBSD, use QEMU to boot up a system
and compile/run tests. More information on that below. and compile/run tests. More information on that below.
[android-docker]: https://github.com/rust-lang/rust-buildbot/blob/master/slaves/android/Dockerfile [Pipelines config]: https://github.com/rust-lang/libc/blob/master/ci/azure.yml
[Cirrus config]: https://github.com/rust-lang/libc/blob/master/.cirrus.yml
[android-docker]: https://github.com/rust-lang/libc/blob/master/ci/docker/x86_64-linux-android/Dockerfile
## QEMU ## QEMU
...@@ -88,9 +73,7 @@ working for these platforms, but the gist of it looks like: ...@@ -88,9 +73,7 @@ working for these platforms, but the gist of it looks like:
We may be able to get it working but it might be difficult at that point to We may be able to get it working but it might be difficult at that point to
ensure that the libc definitions align with what you'd get on the BSD itself. ensure that the libc definitions align with what you'd get on the BSD itself.
As a result, we try to do compiles within the BSD distro. As a result, we try to do compiles within the BSD distro.
* On Travis we can't run a VM-in-a-VM, so we resort to userspace emulation * We resort to userspace emulation (QEMU).
(QEMU).
* Unfortunately on Travis we also can't use KVM, so the emulation is super slow.
With all that in mind, the way BSD is tested looks like: With all that in mind, the way BSD is tested looks like:
...@@ -109,7 +92,7 @@ There's some pretty specific instructions for setting up each image (detailed ...@@ -109,7 +92,7 @@ There's some pretty specific instructions for setting up each image (detailed
below), but the main gist of this is that we must avoid a vanilla `cargo run` below), but the main gist of this is that we must avoid a vanilla `cargo run`
inside of the `libc-test` directory (which is what it's intended for) because inside of the `libc-test` directory (which is what it's intended for) because
that would compile `syntex_syntax`, a large library, with userspace emulation. that would compile `syntex_syntax`, a large library, with userspace emulation.
This invariably times out on Travis, so we can't do that. This invariably times out on CI, so we can't do that.
Once all those hoops are jumped through, however, we can be happy that we're Once all those hoops are jumped through, however, we can be happy that we're
testing almost everything! testing almost everything!
...@@ -194,7 +177,6 @@ Helpful links ...@@ -194,7 +177,6 @@ Helpful links
* https://blog.nekoconeko.nl/blog/2015/06/04/creating-an-openstack-freebsd-image.html * https://blog.nekoconeko.nl/blog/2015/06/04/creating-an-openstack-freebsd-image.html
* https://www.freebsd.org/doc/handbook/serialconsole-setup.html * https://www.freebsd.org/doc/handbook/serialconsole-setup.html
### QEMU setup - OpenBSD ### QEMU setup - OpenBSD
1. Download CD installer 1. Download CD installer
...@@ -233,4 +215,3 @@ Helpful links: ...@@ -233,4 +215,3 @@ Helpful links:
Hopefully that's at least somewhat of an introduction to everything going on Hopefully that's at least somewhat of an introduction to everything going on
here, and feel free to ping @alexcrichton with questions! here, and feel free to ping @alexcrichton with questions!
...@@ -2137,7 +2137,7 @@ fn test_vxworks(target: &str) { ...@@ -2137,7 +2137,7 @@ fn test_vxworks(target: &str) {
"pathLib.h", "pathLib.h",
"mqueue.h", "mqueue.h",
} }
/* Fix me */ // FIXME
cfg.skip_const(move |name| match name { cfg.skip_const(move |name| match name {
// sighandler_t weirdness // sighandler_t weirdness
"SIG_DFL" | "SIG_ERR" | "SIG_IGN" "SIG_DFL" | "SIG_ERR" | "SIG_IGN"
...@@ -2145,7 +2145,7 @@ fn test_vxworks(target: &str) { ...@@ -2145,7 +2145,7 @@ fn test_vxworks(target: &str) {
| "RTLD_DEFAULT" => true, | "RTLD_DEFAULT" => true,
_ => false, _ => false,
}); });
/* Fix me */ // FIXME
cfg.skip_type(move |ty| match ty { cfg.skip_type(move |ty| match ty {
"stat64" | "sighandler_t" | "off64_t" => true, "stat64" | "sighandler_t" | "off64_t" => true,
_ => false, _ => false,
...@@ -2170,13 +2170,13 @@ fn test_vxworks(target: &str) { ...@@ -2170,13 +2170,13 @@ fn test_vxworks(target: &str) {
t => t.to_string(), t => t.to_string(),
}); });
/* Fix me */ // FIXME
cfg.skip_fn(move |name| match name { cfg.skip_fn(move |name| match name {
/* sigval */ // sigval
"sigqueue" | "_sigqueue" "sigqueue" | "_sigqueue"
/* sighandler_t*/ // sighandler_t
| "signal" | "signal"
/* not used in static linking by default */ // not used in static linking by default
| "dlerror" => true, | "dlerror" => true,
_ => false, _ => false,
}); });
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment