Moving Redox OS support to Tier 1

[tertsdiepraam]

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:

1. Investigate how bad the damage is, by building and testing the utils on Redox.
2. Fix some issues that break the entire build for all utils (e.g. the terminal_size issue mentioned below)
3. Figure out which subset of utils that already compiles and adapt this feature set accordingly:
   

   coreutils/Cargo.toml

   Lines 239 to 245 in 1f081f3

   	# "feat_os_unix_redox" == set of utilities which can be built/run on "Redox OS" (refs: <https://www.redox-os.org>; <https://en.wikipedia.org/wiki/Redox_(operating_system)>)
   	feat_os_unix_redox = [
   	"feat_common_core",
   	#
   	"chmod",
   	"uname",
   	]

4. Create a CI job to build, test and lint on Redox
5. Update our platform support page to make the support "official" :)
6. Open an issue to keep track of all the utils that should work but don't.
7. Then we can start accepting fixes to enable more utils.

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:

• Are there examples of projects that already have Redox tests in their CI?
• What subset of utils make sense to support on Redox?

@jackpot51, hope you don't mind me pinging you here. I've tried to follow up on the outstanding issues from #2550:

• filetime seems to have made a release in the meantime here: Bump to 0.2.15 alexcrichton/filetime#72
• termsize has been removed from our dependency tree and replaced with terminal_size (deps: change termsize dependency to terminal_size #3864). However, terminal_size makes no mention of Redox, so I suspect it won't work. We depend on this directly in ls and the coreutils multi-call binary, but also via clap (because we enabled wrap_help feature). So maybe we should first ask terminal_size to support redox. Otherwise we'll have to think about workarounds.
• Do you have any advice for a CI setup that works well in your opinion? Or any opinions/ideas/advice about this effort in general?

cc @sylvestre @cakebaker any opinions on this? Anything I missed?

[jackpot51]

I can make a PR for CI support. That is the best place to start since it will show what other items are broken.

[tertsdiepraam]

That would be great. Thanks!

[jackpot51]

Currently there are some issues with Redox's toolchain being based on 1.68. I'll need to update it again before trying this.

[ids1024]

#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 check test, 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 for onig_sys.

[tertsdiepraam]

Another reason to get rid of onig 😄 Good to hear it's not too difficult!

[ids1024]

cargo check --target x86_64-unknown-redox --features feat_os_unix_redox seems to work without a redox toolchain/sysroot if expr is commented out from feat_common_core, so onig seems to be the only issue with that currently.