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

Allow crate-type=["staticlib","cdylib"] for [[bin]] #6351

Open
retep998 opened this issue Nov 26, 2018 · 5 comments
Open

Allow crate-type=["staticlib","cdylib"] for [[bin]] #6351

retep998 opened this issue Nov 26, 2018 · 5 comments
Labels
A-crate-types Area: crate-type declaration (lib, staticlib, dylib, cdylib, etc.) C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

Comments

@retep998
Copy link
Member

retep998 commented Nov 26, 2018

Cargo currently enforces only one library crate per package which makes total sense for Rust libraries. However it doesn't make much sense for cdylibs or staticlibs which are not going to be consumed by downstream Rust dependencies. Requiring that only the library crate can be a cdylib or staticlib, and not binary crates, sometimes forces people into mixing lib and cdylib or staticlib and Rust currently produces suboptimal results when doing so. It also means people cannot produce multiple cdylibs or staticlibs from a single package.

I'd like to propose extending [[bin]] to allowcdylib and staticlib for the crate-type.

@alexcrichton alexcrichton added the C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` label Nov 26, 2018
@ehuss ehuss added the A-crate-types Area: crate-type declaration (lib, staticlib, dylib, cdylib, etc.) label Apr 6, 2020
@joshtriplett
Copy link
Member

I'd like to see this as well.

I don't know if it makes sense to do this by extending [[bin]], or by adding a new section [[clib]] or similar.

@m-ou-se
Copy link
Member

m-ou-se commented Aug 17, 2020

See #8628.

@guilhermewerner
Copy link

This is a very good proposal. And I have a use case where it would fit perfectly.

When it is necessary to use the same target to generate a desktop executable, but a cdylib for android and wasm, and a staticlib for ios.

It is related to: rust-lang/rfcs#3180

It would not be possible to use the [lib] target to generate these libraries, as there are #[no_mangle] functions that cannot be present in an ordinary rlib, due to name collision. And that way it is also possible to have several native libraries using just one package.

@crumblingstatue
Copy link

crumblingstatue commented Jun 3, 2022

This could also be potentially useful for building multiple wasm modules.

@epage epage added the S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. label Oct 25, 2023
@nyurik
Copy link
Contributor

nyurik commented Dec 23, 2023

My current workaround is to use [[example]] section. This way I can create a cdylib binary, while keeping the core functionality in the [lib] that can be reused from other rust code. See sqlite-hashes and sqlite-compressions -- loadable SQLite extensions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-crate-types Area: crate-type declaration (lib, staticlib, dylib, cdylib, etc.) C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Projects
None yet
Development

No branches or pull requests

9 participants