redox: convert to target_family unix

[jackpot51]

Major changes have been happening in Redox since the design of the libstd/sys/redox module. The creation of relibc has led to the development of a POSIX, C API for Redox that supports the vast majority of required functions in the libstd/sys/unix module. This has allowed the use of a separate target family for Redox to be reconsidered, perhaps allowing it to fall under the unix target family and gain support from a large number of crates without requiring any explicit changes.

After such a unification, the one remaining issue is #52331. Solving this requires the potentially breaking change indicated in these four lines. This change adds a path::Prefix::Scheme variant, but only on Redox. Although this would be a breaking change for Redox, all of the supported packages on Redox have already been compiled successfully with this new variant.

I believe that this change will significantly reduce the work required to move Redox OS to Tier 3, with full support for cargo, rustc, and the other rust tools.

The downside is that crates that have both cfg(unix) and cfg(target_os = "redox") defined will not compile correctly on Redox. This would likely break Redox support for some of the crates that have already added specific support for Redox, while enabling Redox support for many crates that only have support for the unix target family.

I would appreciate any feedback on this potential change.

[jackpot51]

Here is a simple example of the kind of support that would be broken:

#[cfg(target_os = "redox")]
fn do_stuff() { /* Redox stuff */ }

#[cfg(unix)]
fn do_stuff() { /* Unix stuff */ }

[lu-zero]

I wonder if:

• would that change in libstd require to use relibc or just implement a redox.rs in the sys/unix?
• the brokenness in crates supporting both would be silent or evident?

[jackpot51]

• The change would be to use the libc crate as is used in sys/unix already, and add Redox specific support where required. Most of the time, it would use libc, which links to relibc already.
• It would be evident on Redox, but silent on all other platforms. The Redox team would take responsibility for cleaning up our own mess.

[lu-zero]

Would that change anything on the link line for the binaries?

I'm trying to figure out if the shortcomings in this approach are negligible compared the compatibility boost.

Recently I did some cross-compilation experiment and not having to deal with libc and friends (as packaged or not by distributions) would be a boon.

[jackpot51]

It already has to link libc

[lu-zero]

So there isn't really a shortcoming beside cleaning up some crates and the problems there will be evident once you try to build.

And and the solution is to just drop the specific code more often than not.

[jackpot51]

Yep, most of the time it will reduce maintenance burden. There are a few special cases where there are things like target_os = "linux", target_os = "redox" and those will have to be kept. winit, for example

[charleschege]

The way I see it is that this is not much of problem if things break to improve Redox since Redox is not yet at a place we can call stable for general use

[lucbf]

Is redox a unix system? If it is I don't mind this change

[BananaLoaf]

It surely will bring more attention to the project, imo it would be a positive change

[jackpot51]

Ok, I think this is agreeable with everyone so far. I will get to work! Starting, probably, with the libc crate

[matiu2]

https://giphy.com/gifs/yosub-girl-taco-why-not-both-3o85xIO33l7RlmLR4I

Why not both?