geo-types: Weaken serde/std and approx/std features#1024
geo-types: Weaken serde/std and approx/std features#1024bors[bot] merged 1 commit intogeorust:mainfrom
serde/std and approx/std features#1024Conversation
Previously, if I wanted only the `std` feature of geo_types, this would enable the `serde` and `approx` features, too. Change these features to be "weak dependency features", so they're only enabled (and their crates pulled in) if the corresponding optional crate is already pulled in for other reasons.
|
Good catch! We added the "std" feature in an attempt to support no-std builds, and in the process it looks like we inadvertently pulled some existing disabled-by-default features into the default build. Is that right? I fear we might have made the same mistake with some of our other no_std crates. |
|
Oh, yes! I hadn't seen that commit/PR. I believe you're right, that's where the Note that the "?" cargo syntax was stabilized in Rust 1.60, so it should be OK for I only use |
|
bors r=frewsxcv,lnicola |
|
Build succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page. |
4 participants
Previously, if I wanted only the
stdfeature of geo_types, this would enable theserdeandapproxfeatures, too. Change these features to be "weak dependency features", so they're only enabled (and their crates pulled in) if the corresponding optional crate is already pulled in for other reasons.CHANGES.mdif knowledge of this change could be valuable to users.I'm always eager to optimize my build process, and this would help with that :-)
But I'm not sure if this could potentially be a breaking change? Ideally, it would be a purely internal change, but I'm not sure if it could cause issues for downstream crates / users. And I'm not sure if a CHANGES.md entry would be needed / what it should say?