[RFC] [breaking-change] don't depend on GCC by default #107
Labels
Milestone
Comments
|
Sounds like a great plan! I'm fine with this as it stands, but I have a suggestion that might make this a bit clearer:
|
|
One thing I forgot to include in my original text is that this also affects the |
bors bot
added a commit
to rust-embedded/cortex-m-rt
that referenced
this issue
Aug 26, 2018
95: [RFC] remove build dependency on arm-none-eabi-gcc (binary blob alternative) r=japaric a=japaric Before this commit we used gcc to assemble external assembly files into object files that we linked into our Rust program. This commit drops the dependency on gcc by shipping the already assembled object files with this crate source code. --- This is an alternative to RFC #91 that doesn't require a breaking change or adding a new Cargo feature and can be implemented right now. See #91 for the rationale of dropping the dependency on gcc. This approach can be applied to other Cortex-M crates like cortex-m-semihosting and cortex-m (would subsume RFC rust-embedded/cortex-m#107). This seems like an overall better approach to me, but before I go opening more PRs I want to hear your thoughts, @rust-embedded/cortex-m closes #91 Co-authored-by: Jorge Aparicio <jorge@japaric.io>
|
PR #108 made this RFC irrelevant. Closing. |
adamgreig
pushed a commit
that referenced
this issue
Jan 12, 2022
95: [RFC] remove build dependency on arm-none-eabi-gcc (binary blob alternative) r=japaric a=japaric Before this commit we used gcc to assemble external assembly files into object files that we linked into our Rust program. This commit drops the dependency on gcc by shipping the already assembled object files with this crate source code. --- This is an alternative to RFC #91 that doesn't require a breaking change or adding a new Cargo feature and can be implemented right now. See #91 for the rationale of dropping the dependency on gcc. This approach can be applied to other Cortex-M crates like cortex-m-semihosting and cortex-m (would subsume RFC #107). This seems like an overall better approach to me, but before I go opening more PRs I want to hear your thoughts, @rust-embedded/cortex-m closes #91 Co-authored-by: Jorge Aparicio <jorge@japaric.io>
adamgreig
pushed a commit
that referenced
this issue
Jan 12, 2022
107: Disable default-features on rand dependency to avoid std version r=japaric a=therealprof Due to the single dependency tree, the attempted use of a std version flips all depending crates to the std version as well which will not compile on no_std systems. Fixes #105 Signed-off-by: Daniel Egger <daniel@eggers-club.de> Co-authored-by: Daniel Egger <daniel@eggers-club.de>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It's very likely that the thumb targets will soon switch to rust-lld as their default linker (see
rust-embedded/wg#160). If we want to achieve the goal of not depending on GCC, by default, to
build Cortex-M applications then we also have to make core crates like this one not depend on GCC by
default. This RFC is exactly about that.
I propose that in the next minor (breaking) release, v0.6.0, we tweak the meaning of the existing
"asm" Cargo feature and that we add a new Cargo feature named "inline-asm". The relationship between
these two features would be as follows:
If "asm" is disabled the
cortex_m::asmmodule will not be present. The crate will not dependon GCC and will compile on stable / beta in this case. The state of the "inline-asm" feature will
be ignored in this scenario.
If "asm" is enabled and "inline-asm" is disabled then the
cortex_m::asmmodule will bepresent and it will be implemented using external assembly files. The crate will depend on GCC
and will compile on stable / beta in this scenario.
If "asm" is enabled and "inline-asm" is also enabled then the
cortex_m::asmmodule will bepresent and it will be implemented using inline assembly (i.e.
asm!). In this scenario, thecrate will depend on GCC and will require a nightly compiler to build.
Extensions
When the Cortex-M API in
core::arch::armbecomes stabilized we'll expose a subset of thecortex_m::asmmodule (see #101) in the scenario where the "asm" feature is disabled. Rememberthat when this feature is disabled the crate will not depend on GCC or on a nightly compiler.
Alternatives
compile_error!) when both "asm" and "inline-asm" are enabled.Unresolved questions
cc @rust-embedded/cortex-m @hannobraun @crawford
The text was updated successfully, but these errors were encountered: