You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm placing my code on this template, and noticed one gotcha which I think you should know about.
The problem is, .cargo/configs of parent folders affect subprojects, and there's seemingly no way to cut this chord. In my case, a subproject does a "raw" (C to Rust) binding that the main project would then like to use.
So: what's the actual problem?
When doing cargo build in the subproject, I get a linkage error:
note: /usr/bin/ld: cannot open linker script file defmt.x: No such file or directory
That subproject doesn't need defmt at all. It's very weird (imho) that the parent folder affects this way, but the ideology behind .cargo/config.toml seems to be that environment stuff goes there, not project specific stuff. I'm trying to find a way to move rustflags
rustflags = [
"-C", "link-arg=-Tdefmt.x",
]
..away from there and into Cargo.toml - but there might not be such a way.
Work-around
Obviously, I can make the parent project into a sister folder, like main and raw. Currently, I am not aware of another means to bypass this. The issue on doing something about in cargo is open since Nov'19.
The text was updated successfully, but these errors were encountered:
Thanks for opening the issue. I have found workspaces are often problematic in embedded projects and tend to avoid them when possible, so didn't consider others would use it like this.
I think I can probably just move the linker script configuration into a build script instead, which should I hope resolve the issue. Will take a look into it when I get a chance.
Well, I thought this should be simple. Unfortunately, it's seemingly impossible to pass the -Cforce-frame-pointers argument via a build script, even though the remaining RUSTFLAGS can all be set in this manner. So, due to limitations of Cargo, I'm not sure there's anything I can actually do about this for the foreseeable future.
If anybody has a solution to this I'm all ears, but at least from reading the documentation I'm not seeing a path forward.
All I can do is recommend avoiding workspaces for embedded projects. Hopefully one day Cargo is more flexible.
In my case, I wasn't really using workspaces. I had a cargo directory setup on the top level, and another one (for lower level C bindings) as a subdirectory. Have split this to two folders, so .cargo/config no longer bothers me.
btw. -Cforce-frame-pointers wouldn't be a problem. The "-C", "link-arg=-Tdefmt.x" is, since it would link in a library I don't want/need in the subdirectory. And those can be moved to build.rs.
I'm placing my code on this template, and noticed one gotcha which I think you should know about.
The problem is,
.cargo/config
s of parent folders affect subprojects, and there's seemingly no way to cut this chord. In my case, a subproject does a "raw" (C to Rust) binding that the main project would then like to use.So: what's the actual problem?
When doing
cargo build
in the subproject, I get a linkage error:That subproject doesn't need
defmt
at all. It's very weird (imho) that the parent folder affects this way, but the ideology behind.cargo/config.toml
seems to be that environment stuff goes there, not project specific stuff. I'm trying to find a way to moverustflags
..away from there and into
Cargo.toml
- but there might not be such a way.Work-around
Obviously, I can make the parent project into a sister folder, like
main
andraw
. Currently, I am not aware of another means to bypass this. The issue on doing something about incargo
is open since Nov'19.The text was updated successfully, but these errors were encountered: