-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make std
an optional dependency
#20
Comments
std
an optional dependency
Note that this implies no- |
Looking at our deps, we have four first-level dependencies:
So that's three deps that are We should also look at our own use of
Based on this, we have a large number of For the remainder, some have equivalents in
Based on the above, we have the following checklist:
|
As part of #20, we'd like to make `std` into an optional dependency for the `gitoid` crate, so it can be used in `no_std` environments. This requires both transitioning usage of dependencies to `no_std`, and moving our own imports away from `std`. As a first step, this commit transitions just the imports which are direct re-exports of things from `core`, to use the original `core` imports instead. We're not ready for `no_std` yet, but this does move us closer. Signed-off-by: Andrew Lilley Brinker <abrinker@mitre.org>
Per #20, we want to make `gitoid` `no_std`-compatible. Three of our deps: `hex`, `sha1`, and `sha2` are `no_std`-compatible. Of those, only `sha2` appears to be able to transition to turn off `std` immediately without impact to the APIs we use. For `hex` and `sha1`, we'll need to update our usage of the APIs to avoid the things that are turned off when the import becomes `no_std`. This commit doesn't undertake the work of actually transitioning the usage, but _does_ update the `Cargo.toml` file to: - Transition `sha2` to `no_std` immediately. - Update our import of `hex` and `sha1` to turn off default features and then purposefully activate the `std` feature. This makes the status of using `std` more clear, and paves for way for removing the manual activation in the future when we've updated our usage of those deps. Signed-off-by: Andrew Lilley Brinker <abrinker@mitre.org>
* feat: change some imports from std to core As part of #20, we'd like to make `std` into an optional dependency for the `gitoid` crate, so it can be used in `no_std` environments. This requires both transitioning usage of dependencies to `no_std`, and moving our own imports away from `std`. As a first step, this commit transitions just the imports which are direct re-exports of things from `core`, to use the original `core` imports instead. We're not ready for `no_std` yet, but this does move us closer. * feat: start move to no_std deps Per #20, we want to make `gitoid` `no_std`-compatible. Three of our deps: `hex`, `sha1`, and `sha2` are `no_std`-compatible. Of those, only `sha2` appears to be able to transition to turn off `std` immediately without impact to the APIs we use. For `hex` and `sha1`, we'll need to update our usage of the APIs to avoid the things that are turned off when the import becomes `no_std`. This commit doesn't undertake the work of actually transitioning the usage, but _does_ update the `Cargo.toml` file to: - Transition `sha2` to `no_std` immediately. - Update our import of `hex` and `sha1` to turn off default features and then purposefully activate the `std` feature. This makes the status of using `std` more clear, and paves for way for removing the manual activation in the future when we've updated our usage of those deps. Signed-off-by: Andrew Lilley Brinker <abrinker@mitre.org>
Finally done! In the end, after all the prior refactorings and improvements to the Next step will be making |
Looking at the current API, I believe most of this crate could be made no-std compatible. The only parts used currently which require
std
are thestd::io
bits, so the question would be what API should/could be presented in no-std context.It looks like moving the
Read
andWrite
traits intocore
is an eventual goal, currently blocked on the fact thatstd::io::Error
involves boxing (and thus needalloc
). The function on theRead
andWrite
traits specifystd::io::Error
as the return type, so they can't move unless/untilstd::io::Error
changes.I'm doing some investigating on how people have dealt with this IO limitation in other contexts.
The text was updated successfully, but these errors were encountered: