Publish `libc-test` on crates.io

[j-vanderstoep]

Right now, libc-test only exists as a subdirectory of this repository. In Android, we've been using crates.io as our primary source of third party packages, and it would be nice for libc-test to not be an exception. This would make it easier for us to enable CI of the libc crate within the Android Open Source Project.

[JohnTitor]

You should use ctest2 for that case. libc-test isn't for external use and it has many tests for other platforms that are redundant for your case.

[j-vanderstoep]

You should use ctest2 for that case. libc-test isn't for external use and it has many tests for other platforms that are redundant for your case.

I'm not sure what you mean by "external use". We're using it to test the libc crate, not something else. It's important that we do this because we link the libc crate against the Android platform's sysroots (bionic) and not against the NDK, so we need to test behavior within the crate and not just the FFI bindings. Testing against bionic benefits the libc crate as well. It allows us catch potential bugs introduced in bionic before they reach the NDK.

Tests for other platforms are not an issue. We ignore them.

I could upload libc-test crate myself, but I figured that one of the existing maintainers would be better suited to own it. Alternatively, I could move Android to pulling directly from github instead of crates.io, but that diverges from how we manage other third party crates, so I'd prefer to not do that.

[JohnTitor]

Hmm, I still don't think "publishing" is the right way here, you should access it via Git. For instance, we use libc-test for ctest2, like: https://github.com/JohnTitor/ctest2/blob/master/ci/run.sh

[Manishearth]

I disagree. There are many reasons why someone may want to follow crates.io versions, but may also still want to test them. In other crates I maintain I've had to field similar requests and various reasons I've seen crop up:

• They have a large codebase which vendors its dependencies and we wish to be able to test them on the platforms they care about with our specific, potentially nonstandard, toolchain (Android is doing this)
• They are packaging Rust crates for a Linux distro and wish to have proper testing as a part of their packaging process
  • See cargo test fails from crates.io tarball unicode-rs/unicode-normalization#38 for a case of this form: in that case we had package size issues (the tests rely on a large dataset) so there was a reason to not include tests in the package. The final conclusion there was to exclude the big tests, but make it so that cargo test would still run smaller tests.

Ultimately, they could use git, but then they need to be able to reliably match git commits with crates.io versions, and that's not always possible (I myself have forgotten to git tag a release, or otherwise messed up)

Basically, this is important for use cases where the environment is somewhat bespoke, and they still want to use versioned crates.io deps (doing git-replacement for everything is just not feasible). In such environments it's important to test the crate being used, since that environment is not one that people would CI for ("AOSP build system environment" and "Packaging environment for $randomdistro" are not typically something folks would accept PRs to test for 😄 )

[JohnTitor]

Thanks for clarifying @Manishearth! So, I'm preparing an initial release for libc-test with libc 0.2.87, it should be available after bors merges #2095.

UPDATE: Published at https://crates.io/crates/libc-test.

[Manishearth]

Thank you so much @JohnTitor !