Add no_std build support #208
Conversation
Based on @jethrogb's core branch and my master branch Plus some extra notes in README
I was also looking into that today 😄. But the intrinsics rely on the C library libm. We could rely on https://github.com/nagisa/math.rs as an alternative, but it does not yet have all the functions the distributions need. |
There was a problem hiding this comment.
Given that your master branch already has the no_std support, most of the effort was already done, right? I suppose if it builds, the changes are good.
Does it make sense to include the CI configuration from https://github.com/dhardy/rand/ with this PR or soon, to prove it compiles and keeps doing so?
I agree about not making ReadRng available at the moment. Let's wait until there is actual demand before deciding to add an (optional) dependency or splitting it off into a separate crate.
| generators with fresh seeds (user must provide entropy) | ||
| - `thread_rng`, `weak_rng` and `random` are all disabled | ||
| - exponential, normal and gamma type distributions are unavailable | ||
| since `exp` and `log` functions are not provided in `core` |
There was a problem hiding this comment.
Nit: sqrt and powf are also necessary.
There was a problem hiding this comment.
They are also fairly easy to derive from the above functions.
|
I think I've implemented this I'm not really sure about the CI stuff; in theory the extra platform tests are useful (the big endian ones in particular have caught some issues), but it's also a lot of extra work for Travis for limited gain. It should be a separate PR though (go ahead yourself if you like). |
I will keep it in mind. Honest interest: I don't really understand the direction/strategy you want to go at the moment (but that is more for the discussion in #205) |
|
I want to get most of the stuff in my branch merged, but it's a huge inter-related thing, so not fair to ask people to review that. Plus there's some stuff in there that maybe shouldn't be merged. So I'm creating separate PRs. Not sure what actual releases will happen however. |
|
That sounds like a lot of work, but is probably the responsible way. |
Add no_std build support
It would be nice to get this merged. I went ahead and modified @jethrogb's #108 with extra code from my master branch.
This misses the
core_iooption; the difference is thatReadRngis not available. I don't consider this a big deal since it's quite easy to re-implement if need be, though if there is significant demand it could be added.Any objections? It's a shame so many features must be disabled, but there's not much we can do about them. Possibly the
f64distributions could be enabled with some workaround; I'm not sure whyexpandlogare not incoresince the intrinsics are; I won't hold this PR up for that though.