What’s the best practice to write a macro to work in both
More details: I have a macro that uses some types and functions from
hash modules, limited to the overlaps of
core. To be able to name these items, I have to have the full path inside the macro code. Now, wether
core is available as the top-level lang library, or
std, that depends on the caller of the macro, but not the macro’s package itself.
What I have started to do right now is to expect all caller package to explicitly have
extern crate core; in the code, if they are not
no_std. But this solution doesn’t feel right.
no_std is not testable at compile-time using
cfg(). Macros are a good reason to actually make
no_std a config, but I couldn’t find any previous discussion from this perspective.
So, what do you think? Are there any better ways to handle this? Should
no_std be a testable config in compile time?