Allow configuring name of generated shared library artifact

[xmo-odoo]

Currently a library named foo will generate an artifact libfoo.dylib on OSX. That's probably the right default, but it's doubly problematic when building CPython libraries (native modules):

• CPython's import statement will lookup the shared library's name exactly (ignoring extension) requiring an import libfoo. The lib prefix is very rarely used in Python (the lib suffix somewhat more so, libfoo might also be the postfix to a Python binding to libfoo e.g. python-libfoo). This is compounded by "accelerator" native modules (as replacements or improvements of pure-python ones) normally being prefixed by _: Cargo would generate lib_foo rather than the expecting _foo
• CPython doesn't look for .dylib files, it apparently only looks for .so files, even in OSX

Being able to provide an exact name for generated library artifacts (maybe platform-wise?) would fix both issues.

I didn't find any way to achieve that via a build script, or the native parameters of cargo build.

[thirtythreeforty]

You would need a pair of new options to fix this cleanly, I think.

The reason is that I can specify several types of libraries to build:

[lib]
name = "foo"
crate-type = ["dylib", "rlib"]

Cargo will build both a libfoo.so and a libfoo.rlib (on Linux; I'm not familiar with OS X). So you would need a way to both specify the name's prefix and set the suffixes for the various library types:

[lib]
name = "foo"
libprefix = ""
libsuffix = {dylib = "so"}
crate-type = ["dylib", "rlib"]

This example would emit foo.so and foo.rlib.

This would allow you to override specific parts of the name for some types of outputs, while leaving sensible and platform-independent defaults for everything else.

Alternately, you could do both in one setting:

[lib]
name = "foo"
crate-type = ["dylib", "rlib"]
exactname = {dylib = "{}.so", rlib = "{}.rlib"}

(And the {} would be replaced with the name.) But I like this idea less.

[xmo-odoo]

Cargo will build both a libfoo.so and a libfoo.rlib (on Linux; I'm not familiar with OS X).

The same on OSX, except the first one is called libfoo.dylib

[alexcrichton]

Would it be possible to just rename the artifact? Cargo's not necessarily striving to be the end-all-be-all of Rust build systems, and it's pretty likely you'll need scripting of some form layered on top of Cargo for integration into projects like this. Along those lines I'd expect a CPython library to run cargo build to generate libfoo.dylib and then afterwards it'd rename the file to whatever it needed.

[virtualritz]

+1.
For people building dynamic libraries that are loaded as plug-ins to other apps (at runtime) this is a commonly required feature as these rarely follow naming conventions of the platform. They often use UpperCamelCase for the name and have extensions like .plugin or no extension at all.

Currently this requires using something likecargo post or, worse, some other build tool like CMake for something that could be trivially added.

I second @thirtythreeforty suggestions for new options.

[ianks]

This is a critical feature IMO. I’m trying to build an easy way to build native Rust extension is ruby and ruby wants .bundle as the dylib name on Mac.

[benkay86]

This feature would also be useful for writing Matlab extension, which end in something like *.mexa64 instead of *.so. I'm kind of surprised there's not already some way to do this, even with build.rs, but having support in cargo would be fantastic.

[weihanglo]

Some other possible solution:

• Not elegant workaround: cargo rustc --lib -- --emit link="mydylib.whatever".
• There is an unstable feature different-binary-name (tracking issue Tracking Issue for different-binary-name #9778) enabling Cargo to set a different file name for [[bin]] targets. Supporting [lib] is also in the discussion.
• Post build script could also help with this (Post-build script execution #545).