mkDummySrc: support freestanding targets
Currently, when building for targets that do not support std, like x86_64-unknown-none, cargo check on the costructed dummy source fails with:
> error[E0463]: can't find crate for `std`
> |
> = note: the `x86_64-unknown-none` target may not support the standard library
> = note: `std` is required by `sallyport` because it does not declare `#![no_std]`
> = help: consider building the standard library from source with `cargo build -Zbuild-std`
>
> For more information about this error, try `rustc --explain E0463`.
To prevent this issue from happening, set #![no_std] for freestanding targets.
Signed-off-by: Roman Volosatovs [email protected]
Motivation
Checklist
- [ ] added tests to verify new behavior
- [ ] added an example template or updated an existing one
- [ ] updated
docs/API.mdwith changes - [x] updated
CHANGELOG.md
Would you be interested in adding a test case to avoid future regressions?
I'd love to, if fact I looked into doing that while working on this, but was not clear how to proceed, so I did not.
I suppose the way to do it would be to add a freestanding target to the CI toolchain to ensure it's picked up with --all-targets?
I'd love to, if fact I looked into doing that while working on this, but was not clear how to proceed, so I did not. I suppose the way to do it would be to add a freestanding target to the CI toolchain to ensure it's picked up with
--all-targets?
I forked your branch, rebased it onto the latest master, and added a commit with a cortex-m #![no_std] example: https://github.com/newAM/crane/tree/fix/no_std
The examples get tested in CI as far as I can tell.
Feel free to take that commit, or remix it however you want :smile:
@rvolosatovs
I'd love to, if fact I looked into doing that while working on this, but was not clear how to proceed, so I did not.
The test suite is a bit disorganized atm so I apologize :sweat_smile:
Here's the approach I'd take (in priority order, but happy to help finish up any steps you don't get to):
- Define a
simple-nostdcrate in thechecksdirectory, which should fail to build viabuildPackageif your improvements tomkDummySrcare commented out (you can usenix build .#checks.x86_64-linux.NAMEOFTESTto avoid having to rebuild the entire test suite just to check this works)
- Ideally the crate would just have some small dependency (also
#![no_std]) which is enough to check for regressions, but feel free to adapt @newAM 's example above if it helps getting started
- The
checks/mkDummySrctests will likely need to be updated with the new expected values. Basically these tests verify what the dummified source looks like so the newly added lines will likely need to be copied in there as well - As a bonus, it might be good to also add a compilesFresh test for the
simple-nostdcrate as well. That test checks that the artifacts from thebuildDepsOnlystep are actually usable by cargo (without having to rebuild) which won't hurt to check
Feel free to ask if you have any questions!
@ipetkov apologies for the delay, but I have just updated the PR, PTAL.
Note that the issue is not in #![no_std] crates, it's in compiling for freestanding targets. Freestanding targets lack a standard library and therefore cannot be compiled for:
1.) when no_std is not set
2.) when the bare-minimum required runtime handlers are not defined
Hmm.. I failed to reproduce the error in the check, let me do another iteration
Done, https://github.com/ipetkov/crane/pull/126/commits/758ee594f6faaafbfe759459fd7364709dcb1c50 can be used to reproduce the error on latest master (nix build -L .#checks.x86_64-linux.noStdFreestandingTarget).
This error is fixed in the following commit.
This looks great, thanks again @rvolosatovs!
I've pushed some very minor fixes which weren't even worth mentioning here, will merge as soon as CI passes!