xous-rs: use target_os and target_arch cfgs
#252
Conversation
Look at `target_os` to determine whether to enter "hosted" mode or not. If `target_os` is "xous", then the Xous standard library should default to using builtin Rust libstd features. If it is "xous", then we should instead use our arch-specific implementations. This enables third-party programs to directly use the `xous` crate without specifying feature flags. Signed-off-by: Sean Cross <sean@xobs.io>
|
As an example of the sort of error this addresses:
By making this change, out-of-tree packages will be able to use |
|
Hmm I guess I'm confused about the definitions of target vs host. I thought that the "host" was what's running Xous, and so for hosted mode, the host OS would be eg windows/linux, but the target is still Xous. But I guess you're saying in hosted mode, the target OS is no longer Xous... Ah, I see. Checking the definitions, the "host" is where the compiler tools are located, and the "target" is where the program runs. So I guess even though you're 'running' Xous, the actual executable is running on windows/linux/etc. so the equivalent of hosted mode is I think this patch needs to be expanded to normalize the method of determining if you are running in hosted mode. Would you say that this is an "ironclad" method of determining if you're in hosted mode?
There are no edge cases where this would fail? |
|
The only edgecase where that would fail is if we somehow get Xous to the point where it's running its own programs under its own hosted mode. Aside from that, We build for "riscv32imac-unknown-xous-elf". The 3rd entry in the target triple is always the |
|
Alright. I will add some more stuff to this PR then. |
In general, hosted mode is assumed "by default" if the target is not Xous. This allows packages to be built cleanly on command lines that don't know to pass a --feature flag to specify a target. However, an explicit "hosted" flag is still retained so that we can confirm the build system intent. This saves us from the failure mode that we thought we were building for target A, but accidentally ommitted the flag, and instead we've been silently building for "hosted" mode without any warning. The main consumer of the "hosted" flag is now just the build.rs script inside of the utralib.
|
I did a search/replace normalization of references to "hosted" mode and replaced them with the target_os method. Also I've gone and bumped the package version numbers, once those are all published to crates.io i'll merge the patch. |
Look at
target_osto determine whether to enter "hosted" mode or not. Iftarget_osis "xous", then the Xous standard library should default to using builtin Rust libstd features.If it is "xous", then we should instead use our arch-specific implementations.
This enables third-party programs to directly use the
xouscrate without specifying feature flags.