Environment variable to identify the library name

[azam]

Problem

Cargo allows for building libraries having different name than the crate name (name field on [package]) via the name field on [lib], such as given the following manifest, crate name will be goodname but built library will be named libothername.so or so.

[packege]
name = "goodname"
version = "0.1.0"
edition = "2021"

[lib]
name = "othername"
crate-type = ["cdylib"]

For binaries, we have CARGO_BIN_NAME being populated with similar target name for binary on tests etc, but we do not have the equivalent of it for libraries, thus my request is to have CARGO_LIB_NAME, or any suitable variable name that will be populated with the target library name, having same behavior as CARGO_BIN_NAME.

Proposed Solution

Add an env var CARGO_LIB_NAME to be populated with the value set on name field on [lib], if set or default to package name.

Notes

Ref:

• name field on target
• Environment variable to identify the binary name #8251 Environment variable to identify the binary name
• Cargo allows you to have a different name in [lib] and [package] when publishing #6827 Cargo allows you to have a different name in [lib] and [package] when publishing

[epage]

Could you expand on your use case for a CARGO_LIB_NAME?

[azam]

For my specific use case, I am using pgx to create a Postgres extension, and currently it uses the package name to get to the compiled target library file to copy to Postgres directories in order to load it for tests. Since library name can be different than the crate name, currently it cannot find the renamed library as it is trying to match to package name.

See here

[epage]

So more specifically, you are needing a way for a test target to find the lib target's file name?

How would CARGO_LIB_NAME fit into that as it would only be set within the lib target?

FYI Integration tests have access to CARGO_BIN_EXE_<name> in case knowing of that precedent is useful

[azam]

Yes, that would be correct.

pgx test framework gets the compiled binary from the build directory, strips the lib prefix, so that it matches Postgres extension name conventions, matches extensions to the architecture and copies over the compiled library to Postgres. Currently CARGO_PKG_NAME is used with the assumption that library name is the same as package name. Having the library name exposed as an env var would be helpful in knowing the target file without parsing the whole cargo manifest.

CARGO_BIN_EXE_<name> would be useful if we are to find for executable binaries, but this is the case for library, where there can only be one library for a package, unlike binaries.

[epage]

My calling out of CARGO_BIN_EXE_<name> was more so to serve as an example of behavior you might more closely want, a CARBO_LIB_PATH or something.

[azam]

Oh, got it. CARGO_LIB_PATH as suggested, might be as useful as well. My request for just the library name on CARGO_LIB_NAME is because it was sufficient for my use case, and also it would be on feature parity with CARGO_BIN_NAME.

[epage]

Find an artifact by CARGO_LIB_NAME is relying on implementation details of the target directory which will become more difficult with #14125 and #15010.

I also believe CARGO_BIN_NAME is only set on that one crate within the package. So that would be similar with CARGO_LIB_NAME. Tests would not have access to it.

[epage]

I wonder if you could have an artifact dev-dependency on yourself...