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

corrosion_link_libraries behavior vs. expectation #505

Open
Felix-El opened this issue Apr 22, 2024 · 1 comment
Open

corrosion_link_libraries behavior vs. expectation #505

Felix-El opened this issue Apr 22, 2024 · 1 comment

Comments

@Felix-El
Copy link
Contributor

I found cargo_link_libraries behavior, which according docs is essentially the equivalent to target_link_libraries(), to behave somewhat contrary to expectation.

cargo_link_libraries really just adds -l <lib> and -L <libdir> whereas from target_link_libraries I can at least expect that transitive dependencies are considered (our Rust library might link some FFI).

Additionally, target_link_libraries also supports linking by full path and if a non-target is passed, it is assumed that it is a system library -l <non-target-lib>.

Should not the same be offered by cargo_link_libraries?

@jschwe jschwe changed the title cargo_link_libraries behavior vs. expectation corrosion_link_libraries behavior vs. expectation Apr 23, 2024
@jschwe
Copy link
Collaborator

jschwe commented Apr 23, 2024

Sure, all of that would be great to have - pull requests are very welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants