Passing specific rustflags/linker flags for a single project in workspace


#1

There appears to be a breakdown on several fronts to provide a way to control link flags for specific targets in a workspace.

The link flag I need to use in certain cases is: -Wl,--warn-unresolved-symbols. At the moment, it isn’t possible to emit this flag from a build script, and it isn’t possible to use a crate attribute to emit it either.

It’s possible to use .cargo/config to specify the rustflag to emit it. But as I just learned, cargo configs aren’t evaluated in subdirectories belonging to sub-crates of a workspace. So specifying this in a crate level config won’t do a thing if you run the build from the workspace root.

Ok, so next trick, maybe using [target.'cfg(feature="foo")'] instead of [build] in the workspace level config, but as far as I can tell, this has no meaning at all since cargo build -p some_exe --features=foo doesn’t propagate the feature to the sub crate. And certainly doesn’t appear to correctly enable the section of the config.

The only option is to use the workspace level config, or use an environment variable which just means the build doesn’t work in the general case, or worse, it’s incorrect in the general case. Or you don’t use workspaces, which is also not ideal at all.

I think the ability to use slightly uncommon linker settings needs to be addressed because there are plenty of use cases for using them (plugins, cross compiling). I don’t mind jumping through some hoops, but I’d prefer the hoops actually exist.

What I’d like to propose is when building a workspace, the cargo config can be amended at the sub-crate level.

Root config:
/projects/workspace/.cargo/config

When building the sub-crate @ /projects/workspace/components/foo if a .cargo/config exists at that crate root it’d provide any overrides or settings required.

Right now this only works if I change to that crate directory and build there. I do not yet know anything about the implementation of cargo configuration resolution but it seems like that’s the best place to start to provide a solution.

Perhaps this was already proposed and avoided for some reasons I’m not aware of? Are others working on solving this problem from another angle?


#2

Or perhaps another option would be to support [build.foo] sections in a workspace level config?