better dependency handling/profile management/etc. for workspaces

[froydnj]

Some projects (my context is Firefox, but I can imagine others) may want to manage multiple in-tree Rust libraries (one Rust staticlib per shared library the project generates, some libraries for inclusion in shared libaries and some for inclusion in binaries, etc. etc.). You can do this today with multiple Cargo.toml files and tying them together with workspaces.

There are some things about this which are not ideal. Consider:

• Dependencies have to be re-specified in every sub-Cargo.toml. I think if you're going to trouble yourself to use workspaces, it's reasonable that you can list all the dependencies that you need in the root Cargo.toml file and go from there. This issue is particularly acute for codebases (such as Firefox) where all the Rust code must live in-tree, as path specifications are needed for every dependency in every sub-library. It would be much simpler to specify everything once in the root Cargo.toml. I can certainly imagine issues where a particular sub-library might want to use a different version, though...
• Likewise, profile settings have to be re-specified for every library.

It would be super-helpful if settings such as the above (and probably others that I'm not thinking of because they haven't come up in my context) could somehow be shared between library-generating crates.

What would solve the problems above for me would be permitting multiple [lib] sections in a Cargo.toml; I wouldn't need to use workspaces at all if multiple libraries could be specified in the root Cargo.toml! I can understand that it might not be practical to change that at this point, despite the consistency benefits it would bring...

[larsbergstrom]

cc @alexcrichton @wycats @aturon

(more discussion from the Firefox context is here - https://bugzilla.mozilla.org/show_bug.cgi?id=1231764 )

[alexcrichton]

Cargo is likely never going to be on a path to allowing multiple [lib] sections in Cargo.toml, and the theory is that all crates are intended to be their own independent units, e.g. they specify their dependencies exactly.

I'd love, however, for workspace profiles to be fleshed out a bit more. I do think that it probably makes the most sense to default to using the workspace profile rather than the local package profile, especially if one isn't specified.

[matklad]

Likewise, profile settings have to be re-specified for every library.

Profiles are now per workspace (#3249)

Dependencies have to be re-specified in every sub-Cargo.toml

I am not sure that mass specification of dependencies is even theoretically possible. If some local crates depend on each other, how would you figure out the order they should be build in?

[carols10cents]

It sounds like the profile issue here was solved with #3249, and the dependency issue may not be possible to solve, so I'm going to close this issue. Please reopen if I've misunderstood, thank you!