serde feature is incompatible with no_std

[CryZe]

The serde-1 feature is still always compiled with its std feature, meaning that indexmap's serde feature is not no_std compatible.

[bluss]

Thanks. What's your opinion on the feature detect approach to no-std that indexmap uses?

[CryZe]

I think that's mostly fine. Although I'm not sure how you could pass that on to serde.

[jplatte]

I think in general this is not possible given cargos rudimentary implementation of crate features. Even if there was a std feature, it would not be possible to enable serde/std only if this crates std and serde features are enabled. Doing std = ["serde/std"] under [features] would "activate" the serde dependency when the std feature is enabled, even without the serde-1 feature being enabled. Unfortunately I can't find a bug report about this in cargo's issues.

I'm also pretty sure that interacting with dependency resolution from within a build script is not possible (and doesn't seem very viable to me in general).

[CryZe]

Doing std = ["serde/std"] under [features] would "activate" the serde dependency when the std feature is enabled, even without the serde-1 feature being enabled.

Don't tell me this is real????? I haven't fully tested the no_std support for my crate yet (or rather how std behaves then), but that would be horrible.

[cuviper]

I believe the main cargo bug on mixed features is rust-lang/cargo#2589.

The detected std ability actually sidesteps this problem since cargo is not involved, which is interesting, but serde would need to do this too.

[jplatte]

Don't tell me this is real?????

Found it afterall: rust-lang/cargo#3494

@cuviper You are right, that would be an interesting workaround. I'm sure there are some pitfalls though...

[bluss]

I think we can solve this with a new feature like serde-no-std, subset of current serde feature