Open FrankvdStam opened 3 years ago
My understanding is it is a missing feature that other have been asking for in different forms. Found #7004 first which is simmilar.
I am also running into the same issue (more or less). I am trying to change the rustflags to link against opengl and a few other libs which has to happen at the end in my case because I am also working with cxx but I don't want the rustflags to get modified for all crates in my workspace. At this time the subdirectories' configs in the workspace are ignored and only the main config is used.
The current workaround seems to be running cargo
from within the crate's workspace which some people have been creating makefiles for.
Also just found this which seems it might be a solution (but it does require a build script): https://github.com/rust-lang/cargo/pull/8441
+1 encountered the same issue setting up a workspace that targets different microcontrollers
Unsure if bug or asking for a feature.
Problem
When using the new
per-package-target
feature in nightly builds, any linker scripts that you might need in a specific crate will not be found when using a workspace. The linker script is expected in root.Given the following project structure and manifest files:
cargo build will eventually fail during linking:
Even though the script is right there in the crate's subdirectory.
After copying memory.x to the root directory, cargo build runs without problems (except for all those warnings I should really look at)
I would expect the script (memory.x) in the crate directory itself to be picked up. The way that this is setup, I wouldn't be able to target multiple microcontrollers requiring a different memory.x script from the same workspace. I can't specify the name either; "link-arg=-Tlink.x" just looks for memory.x and that's it. In order to target different microcontrollers, you'd have to swap the file in the root directory during build or some crazy shenanigans like that.
Steps
Possible Solution(s)
Maybe the best would not be to just make it pick up memory.x from the specific crate, but allow users to explicitly tell cargo where to find memory.x in Cargo.toml - the first time I saw memory.x I was confused how/where it was used/what it was, an explicit setting might help users find the documentation for it on their own. Then again I have no idea as to the complexities of implementing any of this.
Notes
Output of
cargo version
:Output of
rustup show
: