search

JuliaGeo / GDAL.jl

Thin Julia wrapper for GDAL - Geospatial Data Abstraction Library
MIT License
90 stars 13 forks source link

Propagate a PR from GDAL to GDAL.jl to ArchGDAL.jl for testing #133

Closed mathieu17g closed 2 years ago

mathieu17g commented 2 years ago

@visr considering OSGeo/gdal/issues/5115, I have started by setting up my environnement to be able to make a PR on GDAL. Now I should be ready. Before starting I would like to know how to propagate it to an ArchGDAL PR. I guess that I have to: 1) build a new gdal_jll from my dev branch on GDAL with BinaryBuilder.jl 2) put it as GDAL_branch_name in Yggdrasil/tree/master/G/GDAL, if several version can coexist there, in Yggdrasil/tree/master/G with another name otherwise 3) make a PR on GDAL.jl based on this jll with the adhoc modifications to expose ogr_f_stealgeometryex 4) make a PR on ArchGDAL.jl using the new gdal_jll and GDAL.jl function 5) wait for a new release of GDAL and its transposition in GDAL.jl

Could you please correct my guess ?

visr commented 2 years ago

So far there has only been one GDAL_jll line, which has followed the GDAL releases, with only a few patches to make the cross compilation work for all those platforms.

What would be the most simple is that we wait until a GDAL release that includes your new feature, and then do a new patch. I don't think we should do (2) in either form. If your GDAL patch is accepted and we know it will be in the next feature release and cannot wait for it, we could consider backporting the patch to the last release and include it as a patch in https://github.com/JuliaPackaging/Yggdrasil/tree/master/G/GDAL/bundled/patches.

Or are you just looking for a custom GDAL_jll for your own testing? Because it is also possible to build a custom JLL locally, see https://docs.binarybuilder.org/stable/building/#Building-a-custom-JLL-package-locally.

But indeed once a new GDAL_jll lands, and it contains a new feature that we will wrap in GDAL.jl and use in ArchGDAL.jl, then we need to require that version and tag new releases for those packages. For bugfix GDAL_jll builds, there is nothing that we need to do, since Pkg will install it for us automatically.

mathieu17g commented 2 years ago

Thanks a lot I will look into building a custom JLL package locally

visr commented 2 years ago

It looks like instead of deploying locally you can also deploy to your own repository. Then we can point GDAL.jl to that repo with a Manifest.toml in a branch for testing.

visr commented 2 years ago

@mathieu17g look at that, after #136 a shiny new function appeared :)

https://github.com/JuliaGeo/GDAL.jl/blob/68d8c3f0ba14e87f7c93be36381bc86c24866e1d/src/libgdal.jl#L25166-L25189

Available in GDAL.jl 1.4