Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue: expand CI testing #78

Closed
11 of 16 tasks
Thomasdezeeuw opened this issue May 7, 2020 · 9 comments
Closed
11 of 16 tasks

Tracking issue: expand CI testing #78

Thomasdezeeuw opened this issue May 7, 2020 · 9 comments

Comments

@Thomasdezeeuw
Copy link
Collaborator

Thomasdezeeuw commented May 7, 2020

CI support, following the same tiers as rust (https://doc.rust-lang.org/nightly/rustc/platform-support.html).

Tier 1

Tests must pass.

  • Linux: tested.
  • Windows: tested.
  • macOS: tested.

Tier 2

Must build.

  • Android: check only.
  • FreeBSD: check only.
  • Fuchsia: check only.
  • NetBSD: check only.
  • Redox: check using Rust nightly only, stable is tracked here: Fix building on Redox on Rust stable #181.
  • Solaris: check only.
  • iOS: check only.
  • illumos: check only.

Tier 3

Best effort.

  • Haiku
  • Hermit
  • OpenBSD
  • VxWorks
  • DragonFly BSD

Old description:

Currently only Linux, macOS and Windows are tested on the CI but we support (to some degree) many more OSes. We should add more of these OSes to the CI, at least running cargo check. For (Rust) tier 1 architecture/OS combos this should be easy, but for other tiers rustup might not be supported.

@KodrAus
Copy link
Contributor

KodrAus commented Dec 22, 2020

cc @rust-lang/infra I think we have a few repos in rust-lang with fairly extensive CI suites. Can we think of any examples that we could use to bootstrap some broader CI here? I'm thinking particularly of iOS...

@Thomasdezeeuw
Copy link
Collaborator Author

@KodrAus, @rust-lang/infra a little update: tier 2 targets are now all cargo checked, but if it's possible to actually run the tests somehow I would prefer that.

@KodrAus
Copy link
Contributor

KodrAus commented Jan 11, 2021

@Thomasdezeeuw I'm guessing it's more the OS than the architecture that you're interested in for the tier 2 targets?

It looks like we might be able to use MacOS workers in GitHub Actions to run some of the BSDs. Alternatively, Travis CI does seem to support FreeBSD (although I can't find any docs on it), which we do still use in some repos here in rust-lang (specifically stdarch and stdsimd).

@Thomasdezeeuw
Copy link
Collaborator Author

@Thomasdezeeuw I'm guessing it's more the OS than the architecture that you're interested in for the tier 2 targets?

Yes let's start with the OS. I think if we can run tests on all supported OSs, on any architecture, we can ensure the functionally works. Than cargo check would be enough for different architectures just to make the we got the libc definitions and functions right.

It looks like we might be able to use MacOS workers in GitHub Actions to run some of the BSDs. Alternatively, Travis CI does seem to support FreeBSD (although I can't find any docs on it), which we do still use in some repos here in rust-lang (specifically stdarch and stdsimd).

There is also https://cirrus-ci.org/ for FreeBSD, e.g. Mio uses the following file: https://github.com/tokio-rs/mio/blob/04050dbd87d7b79c33168c6a972a8bb35cf510f8/.cirrus.yml.

@Thomasdezeeuw Thomasdezeeuw removed this from the V0.4 milestone Jan 19, 2021
@Thomasdezeeuw
Copy link
Collaborator Author

Don't think there is much left to do here, so closing.

@jkelleyrtp
Copy link

I believe WASI can be supported since their lib-c exposes sockets. I'd be interested in adding it.

@Thomasdezeeuw
Copy link
Collaborator Author

Sounds good @jkelleyrtp. Although last I check (I think version 9/10) WASI didn't allow for the creation of sockets, however that could have changed. In either case the various socket options could still be useful.

@LetsMelon
Copy link

LetsMelon commented Apr 16, 2024

I believe WASI can be supported since their lib-c exposes sockets. I'd be interested in adding it.

I would be interested in giving it a try. However, after looking a bit through the codebase, I feel that it might be somewhat complicated and not that easy at the moment.

Sounds good @jkelleyrtp. Although last I check (I think version 9/10) WASI didn't allow for the creation of sockets, however that could have changed. In either case the various socket options could still be useful.

I think that's still true, but there is an open and active proposal to add the functionality to create sockets (https://github.com/WebAssembly/wasi-sockets/blob/f2ffc745086ec7ab168f1244f2b3ef0342bf9ddc/wit/tcp-create-socket.wit#L26 and https://github.com/WebAssembly/wasi-sockets/blob/f2ffc745086ec7ab168f1244f2b3ef0342bf9ddc/wit/udp-create-socket.wit#L26) which is currently in 'Phase 3 - Implementation Phase (CG + WG)'. The proposal has been already introduced in WASI Preview 2 which the newly announced target wasm32-wasip2 follows. In the introduction blog post under Conclusion it's encouraged to use cargo-component until the newly created target achieves tier-2. In cargo-component I found a reply from @sunfishcode to an issue that 'work on supporting that (Preview 2, sockets) in libc is underway'.

At the time of writing, WASIX has support via sock_open() to create sockets.


I'm just a random user who stumbled upon this problem: socket2 cannot be built with the target wasm32-wasi. I'm not a wasm/wasi wizard, so please correct me if I have made an error or overlooked something.

@Thomasdezeeuw
Copy link
Collaborator Author

Let's have the discussion in the other thread (#268 (comment)).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants