*BSD support?

[carllerche]

Hey, great work.

I was wondering if it is possible to support the various *BSDs as part of the platforms? I've definitely had issues with Mio breakage.

[japaric]

cross build for *BSD shouldn't be too hard to implement. It's possible to cross compile to those targets from Linux and the instructions to build the cross compilers are here

cross test would be much more complicated to implement and, I expect, very slow. It would require spinning up a QEMU VM per "test runner". (one for every file in the tests directory)

[carllerche]

I do believe that the libc crate does use qemu to get freebsd testing: https://github.com/rust-lang/libc/tree/master/ci

It definitely wouldn't be fast...

[japaric]

Yeah, I'm aware of how libc tests the *bsd targets. The tricky part is doing something like that transparently when cross test is used.

It would require spinning up a QEMU VM per "test runner

I have an idea to avoid this and keep the command transparent but I need to think more about and then prototype it (for Linux targets, first).

[nagisa]

The failure mode is not ideal:

error: could not execute process /target/x86_64-unknown-freebsd/debug/deps/testexe (never executed)

[jan-hudec]

Would the new target.*.runner configuration option in cargo (rust-lang/cargo#3954) help? It should make almost anything transparent.

[gnzlbg]

I am also interested on this. Would it somehow be possible to get FreeBSD, NetBSD, and OpenBSD testing going? I get that Dragonfly is impractical because there is no rust-std components for them though. @malbarbo @japaric I'd be willing to work on this, would any of you be able to mentor me?

[bgermann]

I would also be willing to work on this (to enable Solaris tests). I guess with such a test runner in place libc would be willing to use cross for their testing.

I would suggest the following approach to cross compile and then run the tests in Qemu:

For a cross test --target <triple> ... invocation with an unsupported triple do the following:
1a. Run cross test --target <triple> --no-run ... natively.
1b. The test runner starts Qemu with a TUN/TAP device attached (hopefully this is possible with Travis CI docker containers). Error if no Qemu machine to emulate the given target triple is available.
2. The Qemu image's operating system has Cargo and a TCP service preinstalled that listens for incoming remote Cargo calls (consisting of the given command line arguments, the Cargo.toml and a tar with the compiled tests). Any suggestions for the RPC format?
3. The test runner packages the resulting target files from 1a in a tar.
4. The test runner waits for the service to become available.
5. The test runner calls the service with the ... command line arguments.
6. The service unpacks the tar and builds the appropriate directory structure with the Cargo.toml.
7. The service calls cargo test ....
8. The output is sent as a RPC response.
9. The test runner outputs the RPC response.

I do not know if the Rust source is needed in this scenario. If yes, then the tar would have to contain it as well.

[Dylan-DPC-zz]

I feel this has been resolved by multiple Prs (can't find the exact numbers) so i'm closing this. If you feel that any platform is still missing, you can open a new issue.

[bgermann]

The cross test support is not resolved at all!

[gnzlbg]

There are 3 BSD targets supported by cross:

• x86_64-unknown-dragonfly
• x86_64-unknown-freebsd
• x86_64-unknown-netbsd

and, the support matrix, shows that none of these can run tests. @Dylan-DPC is the support matrix outdated ?

[Dylan-DPC-zz]

@gnzlbg yeah the test support isn't added yet, will create a new issue. This issue is stagnant for a long time, so better to create a new one. Thanks