Repository navigation
Moving Redox OS support to Tier 1 #5210
Description
Activity
I can make a PR for CI support. That is the best place to start since it will show what other items are broken.
That would be great. Thanks!
Currently there are some issues with Redox's toolchain being based on 1.68. I'll need to update it again before trying this.
#5502 fixes the build on Redox. Not too many things needed to be changed.
A very easy way to do CI tests for different platforms is to just run a
cargo checktest, which for pure Rust code doesn't require a sysroot or linker and will catch most compile issues. Though for uutils this fails at the build script foronig_sys.Another reason to get rid of
onig😄 Good to hear it's not too difficult!cargo check --target x86_64-unknown-redox --features feat_os_unix_redoxseems to work without a redox toolchain/sysroot ifexpris commented out fromfeat_common_core, soonigseems to be the only issue with that currently.In other areas of the codebase the default regex utility was implemented with the regex with a TODO to say that it does not have the full GNU regex syntax support. Was wondering if we could add a feature flag that would be able to support using the regex crate in expr without the full GNU compatibility as a backstop for now to enable Redox to use it since to remove onig with a fully compatible implementation does not seem to be possible for a while or until a new dependency that has those capabilities is built
What is the regex crate missing?
I believe it's just back-references and look-around that's missing. I think all of the other available crates currently that support those two features are all just wrappers for c libraries such as onig
Reacted by Jeremy SollerIs there any "prebuilt" redoxer we can use at CI?
We currently only have redoxer pre-built in the redoxos/redoxer docker image. Maybe cargo binstall could provide it?
cargo binstalluses binaries published to GitHub Releases or equivalent, these do not appear to exist: https://github.com/redox-os/redoxer/releases https://gitlab.redox-os.org/redox-os/redoxer/-/releases26 remaining items
@willnode By the way, the
onigurumadependency was removed incoreutils0.12.0.Reacted by Wildan MWe can work around the rustix issue by using libc directly: #14865.
So the remaining blocker is
libc(rust-lang/libc#5530):error[E0425]: cannot find value `FILENAME_MAX` in crate `libc`(https://snoozeth.is/WRBfUbFXXYk) I will wait until https://github.com/rust-lang/libc has tag 0.2.190 and then add a comment.
Resolved.
the https://uutils.org/coreutils/book/platforms.html link in the issue of policy on platform support, is already returns 404, is a dead link
Content was moved to https://uutils.org/coreutils/docs/platforms.html
For context, we recently made a policy on platform support. The gist of that is that a platform is Tier 1 if we have CI for it. I listed Redox there as a Tier 2 platform, because we don't have CI for it.
We want to support Redox OS, because it's an awesome project. uutils is also the default implementation of coreutils on Redox (at least it was when I last checked). However, we have probably accidentally broken support for Redox since #2550. For example in #5064, but there are probably many more failing tests to find. This is due to no fault of the authors of the PRs that broke the support, because it is simply impractical for us to keep compatibility without a Redox CI job. The longer we wait with setting this up, the harder it will be to fix.
I think the way to support this is as follows:
terminal_sizeissue mentioned below)coreutils/Cargo.toml
Lines 239 to 245 in 1f081f3
I'm not sure what the best way is to add a CI job for Redox. We probably need to to set up a VM (similar to how we do FreeBSD).
Some things to explore:
@jackpot51, hope you don't mind me pinging you here. I've tried to follow up on the outstanding issues from #2550:
filetimeseems to have made a release in the meantime here: Bump to 0.2.15 alexcrichton/filetime#72termsizehas been removed from our dependency tree and replaced withterminal_size(deps: changetermsizedependency toterminal_size#3864). However,terminal_sizemakes no mention of Redox, so I suspect it won't work. We depend on this directly inlsand thecoreutilsmulti-call binary, but also viaclap(because we enabledwrap_helpfeature). So maybe we should first askterminal_sizeto support redox. Otherwise we'll have to think about workarounds.cc @sylvestre @cakebaker any opinions on this? Anything I missed?