-
Notifications
You must be signed in to change notification settings - Fork 122
Figure out how to make std work #121
Comments
Depends on a byteorder crate locally patched to make std not a default feature, see #121 for why.
Depends on a byteorder crate locally patched to make std not a default feature, see #121 for why.
From the other direction, if we wanted to spin out
enum Repr {
Os(i32),
Simple(ErrorKind),
Custom(Box<Custom>),
} We can refactor out the (It also uses |
On the other hand, there are some platforms (cloudapi, sgx, wasi, wasm) that make extensive use of an |
BTW the answer from Gitter is patches welcome to xbuild to compile a custom std, but also xargo should still work. |
Depends on a byteorder crate locally patched to make std not a default feature, see #121 for why.
Depends on a byteorder crate locally patched to make std not a default feature, see #121 for why.
There are a couple of annoying things about
#![no_std]
, including:bindgen
that are optionally-no-std are usable. Notably, this includes byteorder, which is both useful in its own right and an indirect dependency of serde-json-core.Vec
); serde-json-core is not.std::io::Write
trait and theimpl Write for Vec<u8>
implementation, so it would be a sizable rewrite to make the crate functional without std.std::ffi
.I think we should try to port over libstd, by making all the filesystem, subprocess, etc.operations just unconditionally return
Err
. (Bonus points if we can raise compile-time errors withcfg
but that seems like a bigger delta against upstream libstd than I'd like.)I'm not sure how to do that, though - xargo would have been the obvious answer in the past. I asked over in the rust-osdev Gitter if anyone has recommendations. And as #38 mentions, we'll probably want a bot to automatically rebase our version of it, until it gets upstreamed. (But I suspect this is a reasonable thing to want to upstream and other projects will want it?)
The text was updated successfully, but these errors were encountered: