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

[Even Rouault]

Greg,

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.

The idea for packaging is similar to autoconf era: that is  you just do 
a build and separate the artifacts into separate packages. That's what 
Alpine (https://git.alpinelinux.org/aports/tree/community/gdal/APKBUILD) 
or Debian 
(https://salsa.debian.org/debian-gis-team/gdal/-/blob/master/debian/rules?ref_type=heads)

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

Even

Le 21/05/2024 à 19:26, Greg Troxel via gdal-dev a écrit :
> I had not gotten to converting the pkgsrc package to cmake, because it
> seemed like it would take a long time.  So gdal is at 3.5.3, the last
> one that works with autoconf.  Yes, I know that 3.5 was about two years
> ago.  It turns out that it is taking hours to do the conversion, and the
> good news is that the main "gdal-lib" package is converted.
>
> I also know 3.5 is not current, but I am trying to convert it to cmake
> (which presumably works fine, given that 3.6 dropped autoconf), before
> updating to newer versions.
>
> I first  tried running cmake in swig/python (in a build dir), but the
> generated makefile doesn't really build anything.
>
> I then tried cmake at top level, and tried to run gmake in swig/python
> and it seems to be building large amounts of things that are not the
> python binding.  Perhaps all of gdal lib and bin.  The install target
> indeed installs libgdal and bin/gdalfoo, regular non-python things, vs
> the expected python tools.
>
>
> The README talks about setuptools.  Should I conclude that cmake is a
> red herring here, despite the presence of CMakeLists.txt?   And that the
> build should just be setuptools in that dir, with no configure stage?
>
>
>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
http://www.spatialys.com
My software is free, but my time generally not.