Support no_std #19
Comments
|
Agreed That's something I wanted to do at the beginning but then left on the side due to lack of time. Outside of the geometry-related algorithms (which relies on collections and memory allocation) it should be relatively straightforward indeed. For some functions maybe we could propose an alternative API where the caller provides preallocated memory (which is the API of the C implementation). |
|
FWIW I poked at this a bit and found and fixed an issue with a dep on no_std: Not sure I'll have time to go all the way though. |
|
Thanks. Any help is appreciated, and even if you don't have time to go through everything, I'll pick it up eventually 🙂 I should have some spare time in the upcoming months, so I'll probably look either at that and/or at the new polyfill algo they implemented recently (I'm curious to see how it performs compared to my optimized version of the current algo) |
|
Little update: I have a working The code still need a little bit of cleanup & documentation, but it's looking good 🙂 And about that:
Surprisingly enough, this proved to be an hindrance 😅 |
|
Wow, that was quick! |
|
Yay, on one hand it was way easier than expected (thanks to the On the other hand, the lack of math functions in |
How it was done
===============
First step was to replace the references to the `std` crate by `core` or
`alloc` when possible.
Which was always the case, except for the `Error` trait which isn't
available in `core` on stable[1].
Another change, that may impact the performance a bit, was to replace
the usage of Hash{Map,Set} by the B-Tree variant, since the hash-based
one aren't available in core (due to a lack of a secure random number
generator).
There should be no visible impact on default build, since we're still
using hashtable when `std` is enabled (which is the default behavior).
Maybe I should give a shot to `hashbrown` to bring back the hashtable
version into `no-std` as well.
The last change was a bit more annoying (and surprising): most of the
math functions aren't available in core[2].
So I've implemented a fallback using `libm` when `std` isn't enabled.
Note that due to Cargo limitation[3] `libm` is always pulled as a
dependency, but it won't be linked unless necessary thanks to
conditional compilation.
Known limitations
================
Cannot use the `geo` feature without `std`, mainly because the `geo`
crate itself isn't `no-std` (as well as a bunch of its dependencies I
guess).
--------
[1]: rust-lang/rust#103765
[2]: rust-lang/rfcs#2505
[3]: rust-lang/cargo#1839
Closes: #19
For embedded and rust-gpu, it would be nice to have std be an optional feature that is turned on by default.
I'm not sure if this is possible / how much standard is needed but from a high level it appears to be a lot of math and lookup tables.
The text was updated successfully, but these errors were encountered: