Add cfg for crate_type?

[joshlf]

I have some code that needs to be conditionally compiled only when the artifact that's being produced is a dynamic library, and the target platform is Mac (here's the code). Right now, I'm accomplishing that by providing a dylib feature that the crate's user is responsible for enabling if they're compiling a dynamic library.

This is ugly from a UX perspective, and introduces the possibility of bugs if the user fails to enable the feature when they should. It'd be better if there were a cfg setting that indicated the value of the crate_type so I could do this automatically without user help.

[hanna-kruppe]

It is possible to set multiple crate types at once and get artifacts for all of them in one compilation session. That makes it kind of difficult to provide a single crate_type="foo" cfg, though perhaps there could still be a set of flags like cfg_crate_type_cdylib, cfg_crate_staticlib, etc.?

[joshlf]

Yeah, I think that'd work. Something like #[cfg(crate_type = "cdylib")], #[cfg(crate_type = "staticlib")], etc (where multiple could be true at once similar to #[cfg(feature = "...")]).

In my particular use case, I'd probably need to ensure that only a single artifact was generated at a time by doing something like:

#[cfg(all(crate_type = "cdylib", any(crate_type = "staticlib", ...)))]
compile_fail!(...);

But yeah that'd work for me.

[glandium]

where multiple could be true at once

Interestingly, that would not be useful in some use cases. Specifically, I was looking at building a crate as both a cdylib and staticlib today, and needed both to export a function under a different name... I tried #[cfg(crate_type = "cdylib")] on function with one name and #[cfg(crate_type = "staticlib")] on another, but that (annoyingly, I must say) silently exposed none of them. This use case would not be fulfillable if multiple could be true at once.

[retep998]

Why don't we just allow a cargo package to have multiple cdylib and staticlib crates distinct from the primary library crate? Then you could just put all the common stuff in the library crate and the cdylib/staticlib crates would have the stuff specific to them, so you wouldn't have to cfg based on how the crate is being built.

[joshlf]

My concern would be that it'd require publishing the common crate which would need to expose internal functionality in order to be used by the cdylib and staticlib crates. You might not want to actually publish that stuff.

…

On Thu, Mar 1, 2018 at 4:06 PM, Peter Atashian ***@***.***> wrote: Why don't we just allow a cargo package to have multiple cdylib and staticlib crates distinct from the primary library crate? Then you could just put all the common stuff in the library crate and the cdylib/ staticlib crates would have the stuff specific to them, so you wouldn't have to cfg based on how the crate is being built. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#45182 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_2L_NeXfnIEpdugDA0fMuBJG3XAdo0ks5taIzqgaJpZM4P0Yyz> .

[retep998]

Ah, but you could have a shared module. Two separate crates can both include the same module, and that could define the common private functionality.

[glandium]

How can two separate crates share a module?

[glandium]

Ah! #[path].

[Mark-Simulacrum]

I'm going to loosely say this is probably RFC-worthy territory and close this issue (it's definitely not a rustbuild bug).