Build script version detection assumes you're not cross compiling

[sfackler]

The gdal crate declares gdal-sys as both a runtime and build-time dependency, and calls the gdal_version_docs_rs_wrapper function to determine the gdal version.

This logic is broken when cross compiling, since the host system's gdal won't be the same as the target system's gdal. A more robust approach would be to have gdal-sys output the detected version in its build script which can then be picked up by gdal's build script:

https://doc.rust-lang.org/cargo/reference/build-scripts.html#the-links-manifest-key
https://doc.rust-lang.org/cargo/reference/build-script-examples.html#using-another-sys-crate

[rmanoka]

Indeed, this was done to get it working on docs.rs which does a cross-compilation, and we wanted to be able to not rely on the host (docs.rs) having gdal installed. Ref. PR that introduced it for discussion. I believe the standard DOCS_RS flag approach was causing issues for the docs.rs builds of down-stream libraries.

Do you have a MWIP repo to test? I'm not an expert on cross comp.

[sfackler]

The issue isn't related to the docs.rs stuff, just to the fact that this dependency exists at all.

[jdroenner]

Well, if there is a better way, let us use that.

[lnicola]

@sfackler how can gdal know the version that gdal-sys detected without depending on it?

EDIT: looks like https://doc.rust-lang.org/cargo/reference/build-script-examples.html#conditional-compilation is exactly about this.

[sfackler]

It currently depends on gdal-sys twice. This is the dependency that should stay: https://github.com/georust/gdal/blob/master/Cargo.toml#L23

[lnicola]

So if I got this right:

• gdal-sys needs a links = "gdal" clause and can output a cargo:version_number declaration
• cargo makes sure that the gdal build script gets a DEP_GDAL_VERSION_NUMBER env variable with the value set by gdal-sys

That's quite nifty, I didn't know it was a thing.

[sfackler]

Yep!

[rmanoka]

So this means we can also test the docs_rs variable somewhere and output the appropriate env. variables?

[jdroenner]

i guess it should work like this: #377

[lnicola]

Fixed in #377 🎉

[sfackler]

Thanks for the quick fix!