Closed w-flo closed 1 year ago
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 approx
and serde
crates started to be pulled in by default because their corresponding features were not marked as "weak" using the "?" syntax. Now you can only drop them by disabling the std
feature. The std
feature itself is a great addition though.
Note that the "?" cargo syntax was stabilized in Rust 1.60, so it should be OK for geo_types
(MSRV 1.63), but maybe some other georust crates use MSRV < 1.60?
I only use geo_types
and gpx
, and gpx
does not appear to have this issue (but two other issues https://github.com/georust/gpx/pull/91 )
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. For more help, visit the forum.
If you want to switch to GitHub's built-in merge queue, visit their help page.
Previously, if I wanted only the
std
feature of geo_types, this would enable theserde
andapprox
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.[ ] I added an entry to
CHANGES.md
if 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?