Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for Integer64 #80

Merged
merged 1 commit into from
Sep 25, 2020
Merged

Add support for Integer64 #80

merged 1 commit into from
Sep 25, 2020

Conversation

lnicola
Copy link
Member

@lnicola lnicola commented Jul 7, 2020

Fixes #79

@@ -68,6 +71,11 @@ impl<'a> Feature<'a> {
let rv = unsafe { gdal_sys::OGR_F_GetFieldAsInteger(self.c_feature, field_id) };
Ok(FieldValue::IntegerValue(rv as i32))
},
#[cfg(feature = "gdal_2_2")]
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We only need 2.0, but this is a mess anyway :-(.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i guess we have to check if the feature is >= gdal_2_x. Maybe we could do a not "gdal_1_11"? Could you look into this?

My suggestion for the future is to rebuild the crate into feature gated modules.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we could do a not "gdal_1_11"? Could you look into this?

That might end up as any(feature = "gdal_2_2", feature = "gdal_2_4", feature = "gdal_3_0").

My suggestion for the future is to rebuild the crate into feature gated modules.

Sigh. I'm not sure this works too well -- it's an enum variant, after all.

Maybe we could always compile it in, but fail (or panic at runtime) if the feature wasn't enabled?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In #86, I faced a similar issue and made a "superset" feature for the major version, maybe it would make sense to do something similar here?

gdal_2_2 = ["gdal_2", "gdal-sys/min_gdal_version_2_2"]
gdal_2_4 = ["gdal_2", "gdal-sys/min_gdal_version_2_4"]
gdal_2 = []
#[cfg(feature = "gdal_2")]
...

@lnicola lnicola force-pushed the integer64 branch 2 times, most recently from 4cd2e7b to a487a27 Compare July 7, 2020 14:58
@jdroenner
Copy link
Member

@lnicola i created a PR for my idea with the versioned features #81 (this would also drop support for GDAL 1.*)

@lnicola
Copy link
Member Author

lnicola commented Jul 17, 2020

I wonder if it's better to drop support for older versions. It's easier to get an up-to-date GDAL these days.

@jdroenner
Copy link
Member

Would you port this to the feature_gate_versions branch? I think it solves the issues with different versions and i like to merge it into master soon.

@lnicola
Copy link
Member Author

lnicola commented Sep 1, 2020

@jdroenner I'll port it if it gets merged, but it feels like a lot of complexity TBH. Did you pick a solution for the enum versioning?

@jdroenner
Copy link
Member

jdroenner commented Sep 1, 2020

With the change we only support gdal 2 and 3. So i guess the enum can stay in common for now. My idea was to split enums also by version if needed. So we can have different enums for different versions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

OFTInteger64 is not supported
3 participants