Even Rouault <even.roua...@spatialys.com> writes: > If the build requirements for the Python bindings are met (python + > swig available), then a "make && make install" cycle will build and > install libgdal and the python bindings, like it did in autoconf > era. The CMake build target "python_binding" has libgdal as a > dependency.
ok, but > The idea for packaging is similar to autoconf era: that is you just > do a build and separate the artifacts into separate packages. That is how some packaging systems work. Others work differently, and pkgsrc in particular lets you build parts separately. Not so much in this case, but a package that has a base program and a qt binding, or even worse rust, would be beastly to build on a low-resource system. Upstreams can't assume that all packaging systems build the kitchen sink and split it up. and, the readme in the bindings dir says that gdal libs are a dependency. In my case they are installed, as py-gdal depends on gdal-lib. > With 3.9, you could also do a more manual approach (not sure the > python_generated_files target is available in 3.5) > cmake .. > make GDAL # build the library > cd swig/python > make python_generated_files # generate SWIG generated files > python setup.py build Turns out I was able to just ignore cmake and build a wheel in swig/python, as if it was a separate project. This is a great outcome. Thanks for the hints; they are helpful to understand the bigger picture. _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
