[gdal-dev] building just the python bindings (cmake)

[Greg Troxel]

Even Rouault <even.rouault at 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.