Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CARGO_LIB_CDYLIB_<name> #8193

Open
jeff-davis opened this issue May 1, 2020 · 1 comment
Open

CARGO_LIB_CDYLIB_<name> #8193

jeff-davis opened this issue May 1, 2020 · 1 comment
Labels
A-environment-variables Area: environment variables C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-test S-triage Status: This issue is waiting on initial triage.

Comments

@jeff-davis
Copy link

Describe the problem you are trying to solve

The integration test for my cdylib doesn't have a clean way to know where to find the library file itself. My cdylib is actually a PostgreSQL extension (essentially a plugin), so the only way to test it is by actually running PostgreSQL and loading the library. To do that, the integration test needs to know the location of the library file (e.g. ...../target/debug/libxyz.so).

Describe the solution you'd like

I want cargo to set a new environment variable, CARGO_LIB_CDYLIB_<name>, similar to CARGO_BIN_EXE_<name>, that would allow the integration test to find the library in a platform-independent way (and that works regardless of the profile used to build it).

I would like this variable always available, not just for test runs. The reason is that I also have a [[bin]] target that installs the library into PostgreSQL's lib directory (kind of like doing make install for a postgresql extension written in C), so that it can be easily installed.

Notes

Unit tests are not practical in my case, because the plugin accesses lots of Postgres APIs that require a running server.

@jeff-davis jeff-davis added the C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` label May 1, 2020
@ehuss ehuss added A-environment-variables Area: environment variables Command-test labels May 23, 2020
@airtower-luna
Copy link

I'd like something similar, in this case to be able to find a Python module built using PyO3 in a platform-independent way. I'd prefer to have the information in the output (I'm using --message-format=json and parsing it already), but if I can write it to a file from a build script that would also work.

@epage epage added the S-triage Status: This issue is waiting on initial triage. label Nov 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-environment-variables Area: environment variables C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-test S-triage Status: This issue is waiting on initial triage.
Projects
Status: No status
Development

No branches or pull requests

4 participants