Skip to content
This repository has been archived by the owner on Jan 24, 2022. It is now read-only.

Depend on a no_std compatible version of chrono #60

Closed
robomancer-or opened this issue Mar 20, 2018 · 4 comments
Closed

Depend on a no_std compatible version of chrono #60

robomancer-or opened this issue Mar 20, 2018 · 4 comments

Comments

@robomancer-or
Copy link

robomancer-or commented Mar 20, 2018

I'm running into a dependency conflict where I can't depend on uom because it depends on num-traits, which has been made no_std compatible since the most recent version of chrono. The problem is, the released version of chrono depends on a conflicting version of num-traits that requires std. Why cargo can't sort out conflicts of this sort is beyond me, but since it can't, would cortex-m-rt switching to the github version of chrono be permissible (at least until chrono gets their act together and cuts a no_std compatible release)?

To recreate the problem for yourself, all you have to do is start a blank no_std library project, add a dep for

uom = { git = "https://github.com/iliekturtles/uom", branch = "dev-num-std", default-features=false, features =["si", "f32"] }

verify that xargo can build it, then add a dep for cortex-m-rt = "*" and try to build again

@hannobraun
Copy link
Member

would cortex-m-rt switching to the github version of chrono be permissible (at least until chrono gets their act together and cuts a no_std compatible release)?

I'd like to note that crates.io doesn't accept crates that depend on git repositories, so switching to chrono's GitHub version would effectively block new versions of cortex-m-rt from being released.

@robomancer-or
Copy link
Author

...Oh, I definitely didn't realize that, yeah, that's definitely not worth it!

@skierpage
Copy link

https://crates.io/crates/chrono is now at 0.4.1 which is no_std compatible. \o/?

japaric added a commit that referenced this issue Apr 6, 2018
Minor version has been bumped to v0.4.0 so we can stop supporting them

This also drop the chrono dependency, which some people have been running into problems with.

closes #60
@whitequark
Copy link
Contributor

Note that because of rust-lang/cargo#4866 it is not enough for chrono to support no_std to handle every case. Dropping it is the right approach.

@japaric japaric closed this as completed in d812938 Apr 9, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants