yutannihilation opened a new pull request, #114:
URL: https://github.com/apache/sedona-db/pull/114

   This pull request adds a mechanism to avoid running bindgen in sedona-proj 
and sedona-tg. This fixes two of the three remaining problems we found in 
https://github.com/apache/sedona-db/pull/78#issuecomment-3289180614 related to 
cross-compilation on Windows with Rtools.
   
   The mechanism is
   
   1. If there's already `bindings/{OS}-{ARCH}.rs`, use it.
   2. Otherwise, run bindgen and use the newly generated bindings.
       - If `SEDONA_*_BINDINGS_OUTPUT_PATH` envvar is set, output the bindings 
to the path.
       - If not, use `OUT_DIR`, which Rust uses for intermediate artifacts.
   
   So, if we want to update the binding, we can set 
`SEDONA_*_BINDINGS_OUTPUT_PATH` and build the crate. For example, run the 
following to generate bindings to `./tmp.rs` using Rtools45 (I tried both 
`stable-x86_64-pc-windows-msvc` and `stable-x86_64-pc-windows-gnu` toolchain, 
but it seems the result bindings is the same).
   
   ```ps1
   $env:PATH = "C:\rtools45\x86_64-w64-mingw32.static.posix\bin;$env:PATH"
   $env:PKG_CONFIG_SYSROOT_DIR = "C:\rtools45\x86_64-w64-mingw32.static.posix\"
   $env:SEDONA_PROJ_BINDINGS_OUTPUT_PATH = "./tmp.rs"
   
   cargo build -p sedona-proj
   ```
   
   If it's better not to add the prebuilt bindings into the crates, I can tweak 
the mechanism and generate bindings in R's `Makevars.win` (i.e. run `cargo 
build -p sedona-proj` without cross-compilation first, and then use the 
generated bindings via some envvar).


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to