Re-add a hash to the filename at the top level to avoid conflicts with external libs? #1601
Description
This is a follow up to this issue from the rust repo after amazing detective work by @alexcrichton :)
It seems that although 27efa7b correctly points out that it is impossible for conflicts to arise between rust crates, it is still possible for conflicts to arise between external libraries and cargo produced libraries.
This may prove to be a confusing/surprising issue for authors of rust libraries that bind to external / non-cargo produced libraries. It is likely not uncommon for an author to name their crate the same as the external library which they wrap for ease of search-ability. As an example, this is the exact issue we've just run into in the rust-portaudio crate.
Possible solutions:
- Alex mentioned that perhaps it's worth suggesting to re-add a hash to the filename at the top level to allow for this use-case to work, which sounds like a nice way of avoiding related linking issues entirely in the future.
- An alternative might be for Cargo to check for name conflicts and provide a clear error. One issue with this is that the conflicts do not arise until the crate is depended upon (by i.e another lib or an example). I wonder if it is possible to catch this error in advance while compiling the crate that would produce the error?
Personally I'm in favour of 1, though I'm not familiar enough with cargo to understand entirely what is involved :)
Thanks again Alex for the great job on debugging this one!