Just want to make sure I'm heading in the correct direction. In the case where B, C, and D are my crates, nix is a common dependency of B and C.
nix.rlib
/ \
libB.so libC.so
\ /
libD.so
B, C, and D are needed to be dynamic libraries (for dlopen). Does it imply that the only chance for me to build D (and also to make sense of the entire procedure) is to make nix and all its transitive dependencies to produce dylibs for B and C to link with (perhaps by customizing cargo a little bit)? Assume ABI compatibility is achieved by forcing the use of the same compiler. @bjorn3
In my real case, I have more than 30 custom crates and the dependencies are much more complex than in the case described above.
In my setup, I have already written 40k LoC and dozens of crates. The diamond dependency issue appears when I am doing a large refactoring to the codebase. Adding a dylib shim, unfortunately, merely works in the toy case scenario. I guess this is why I'm thinking about whether transparently producing a dylib for each crate and linking them together would work.