-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Feature gate versions #81
Conversation
#[cfg(any(feature = "gdal_2_2", feature = "gdal_2_3", feature = "gdal_2_4"))] | ||
pub mod gdal_2_2; | ||
#[cfg(any(feature = "gdal_2_2", feature = "gdal_2_3", feature = "gdal_2_4"))] | ||
pub use gdal_2_2::*; | ||
|
||
#[cfg(any(feature = "gdal_2_3", feature = "gdal_2_4"))] | ||
pub mod gdal_2_3; | ||
#[cfg(any(feature = "gdal_2_3", feature = "gdal_2_4"))] | ||
pub use gdal_2_3::*; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am confused about this part. So why do you import gdal 2.3 stuff for gdal 2.4?
I though all common implementation is done in common.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is functionality which is exclusive to the 2.x or 3.x branches, so its not common. However, i'm not aware of functionality in gdal 2.x not available in gdal 2.y where y > x.
Just a note for what other folks have done. The openssl crate went down this road of per-version feature flags for a while, but ultimately landed on an approach utilizing build.rs to pass in configuration. see: sfackler/rust-openssl#852 A snippet from their build.rs:
Note that their configs are cumulative - so I think part of why the feature flag approach failed for them is because they had multiple incompatible providers (libreopenssl vs openssl), which thankfully is a problem we don't have to contend with, so maybe it doesn't directly apply. I do think there's something to be said for having the configuration generated automatically by the build script rather than expecting the user to know they need to specify them. |
Maybe this is already known, but just a note to say this isn't currently building for me with the gdal_3_0 feature: output from cargo test --features gdal_3_0Compiling gdal v Compiling gdal v0.6.0 (/Users/mkirk/src/georust/gdal) 0.6.0 (/Users/mkirk/src/georust/gdal) warning: unused variable: `allowed_drivers` --> src/gdal_common/dataset.rs:50:54 | 50 | ...flags: Option, allowed_drivers: Option<&str>, open_options: Option<&str>, sibling_files: Option<&str>) -> Result { | ^^^^^^^^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_allowed_drivers` | = note: `#[warn(unused_variables)]` on by default |
src/gdal_2_2/mod.rs
Outdated
@@ -0,0 +1,2 @@ | |||
mod spatial_ref; | |||
mod vector; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
might want to cargo fmt
before merging
Thank you for the great feedback! The build.rs approach is very nice. We could query gdal-config for the version. |
lol yes, sorry to keep bugging you. It's not urgent for me. Enjoy your vacation. =) |
Just a minor note, adding to @michaelkirk 's points above. Cargo features are additive, so two crates with gdal as dependency might end up enabling contradicting feature gates. If that is a possibility, we could proactively add |
I thought about this PR for some time. I think we will discard the trait based approach and generate cfg flags for versions using build.rs. Will create a new PR for this soon. |
I created a PR where the version is selected at build time based on the installed GDAL version: #92 I think thats the way to go. |
This PR restructures the gdal crate into folders related to GDAL versions.
The idea is to keep common (GDAL ~2.0) functionality in the gdal_common folder and add new functionality in the version folders.
To enable this approach the base types (pointer wrapping structs) are separated from the methods which are implemented in traits.
One example is in the spatial_ref folder: The
SpatialRef
struct is ingdal_common::spatial_ref
and methods are implemented in theSpatialRefCommon
trait. Additionally, new methods (GDAL 3.0) are added ingdal_3_0::spatial_ref
with theSpatialRef_3_0
trait.I think this approach works well and enables to add (and remove) methods for GDAL 2 and 3.
One open question is how to handle enums with different fields: a) add #[cfg()} in the enum or b) put the enums into the versioned folders and use the same name.
Other changes:
Dataset
andDriver
(raster and vector datasets are the same in GDAL >= 2.0)** vector datasets now also return
Layer
not&Layer
->Layer
now keeps a ref toDataset
Buffer
toRasterBuffer
Dataset::open
to use GDALOpenEx