Support no_std on targets without stdlib

[vinc]

Hello, I'm coding a toy OS (https://github.com/vinc/moros) and I'd like to use the time crate to provide a date command. I keep track of time in the kernel so with this crate it'd just be a matter of doing the following:

let date = OffsetDateTime::unix_epoch() + Duration::seconds_f64(timestamp);
print!("{}\n", date.format(format));

The only problem is that I can't compile time-macros for my target:

cargo bootimage --no-default-features --features vga,dvorak --release
Building kernel
   Compiling time-macros v0.1.0
error[E0463]: can't find crate for `std`
  |
  = note: the `x86_64-moros-2162824510176240459` target may not be installed

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: could not compile `time-macros`.

To learn more, run the command again with --verbose.
Error: Kernel build failed

With the following in Cargo.toml:

time = { version = "0.2.16", default-features = false }

This problem has been previously mentioned in a closed issue with a solution that has not been implemented at the moment: #243 (comment)

I'm creating this new issue so that we can track it.

[jhpratt]

The time_macros crate still depends on stdlib. As it's a proc macro, it should be targeting the host, not the target. I'm not familiar with the cargo bootimage command, however. What exactly is it doing?

Ultimately this should work today, so long as you have a global allocator. If you don't, that's being tracked in #249. It is standard practice for proc macros to rely on stdlib, though.

[vinc]

Thanks for your reply, cargo bootimage uses cargo xbuild to do cross compilation from the host to the target. So it seems that's what is blocking compilation of time_macros? My OS has a global allocator and I'm using some no_std crates with alloc.

[jhpratt]

It looks like the relevant repo is rust-osdev/cargo-xbuild. Possibly related might by rust-osdev/cargo-xbuild#10 and rust-lang/cargo#7915.

Without knowing exactly how cargo xbuild works (I've never used it myself), I would assume that it still runs proc macros on the host. One thing that might be worth checking is if time is used anywhere else in your dependency tree (cargo tree should suffice), where the std feature might be enabled. I'd expect a different error in that case, but you never know.

#243 is an unrelated issue, and was fixed a while back.

[vinc]

Thank you for the links and researching this issue, like this comment rust-osdev/cargo-xbuild#10 (comment), I wasn't able to fix it with -Z features=host_dep so for now the solution seems to fork this crate and put time-macros under a feature flag as explained here: #243 (comment)

That seems acceptable until the situation evolve for cargo xbuild.