@jethrogb Hi, I'm so glad you are interested, and I'm sorry for not
following up sooner. I don't think there are any obstacles to proceeding,
as refactoring in this direction seems fairly unobjectionable.
There are a few ways to proceed, but I think getting to the point
where you can implement a custom std out of tree will be a long road.
For refactoring std, the easiest thing to get started is by cutting
down entries in the tidy whitelist, where std is not using conditions
in the right modules. These are easy patches to make and review.
Someone could also be bold and create the pal_common / pal_unix /
pal_windows crates and wire them up to the build system. I suspect
that would get past review with some debate. After that there will be
a long slog of puzzling out how to pull pieces out. I mentioned some
other next steps in my op. And remember my linked branch has
uncommitted refactoring steps that, while bitrotted, demonstrate some
sequences that work to untangle dependencies.
As far as your end goal of creating a std port that excludes large
chunks of std, for now I would focus on creating a port that fits into
the model described here, where the customization is at the sys/pal
layer. Today, I would suggest that, instead of trying to compile out
parts of std your port doesn't use, settle for panicking instead. In
the longer term, when std has scenarios, then we can actually remove
the unsupported features. This might involve a custom platform
libstd/sys directory, and ultimately a custom pal crate.