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

[Even Rouault]

Le 22/05/2024 à 16:59, Greg Troxel a écrit :
> I got 3.5 to work, so I'm focusing on the 3.9 upgrade.   It seems that
> 3.9, vs 3.5, has withdrawn the swig generated files from the distfile.
>
>    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
>
> That looks like it works.  Except that I omitted the 'make GDAL'  -- in
> my case, gdal is already installed.   I don't see why one would need to
> build, as long as the headers and libs are available in the system.
> Does that seem reasonable, or am I missing something?
The  GDAL Python (or CSharp or Java) bindings, being in-tree, have a 
special status compared to other bindings in dedicated code repository, 
since they get built as one of the many components built by the build 
process, and do not rely on installed libs/headers in the default 
process. You've figured out it is still possible to build a wheel (or 
use the source pakage on pypi https://pypi.org/project/GDAL/ which are 
generated following the procedure documented in HOWTO-RELEASE) that will 
manage to find the installed libs/headers
>
> It would be great if README in swig/python explained this.  The
> "installation" instructions are more pointers to packaging systems, and
> not so much guidance for people trying to build from source.  I realize
> that almost all people who use gdal use it from packaging and do not
> have the slightest idea how to build perhaps anything, but on the other
> hand I would expect that a README in the sources is only read by people
> who are trying to build it.
Feel free to contribute documentation :-)
>
> Also in README, it talks about numpy being a depdendency but not
> formally required.   I think two clarificaions would be useful:
>
>    What is lost specifically, vs "many examples and utilities"?  If you
>    use it with qgis, without numpy, are things missing there too?  I'm
>    willing to believe it's a big deal, but it's hard to understand.
>
>    I am guessing that the things that need numpy work fine if you install
>    this built in an environment without numpy and then later also install
>    numpy, but it is unclear if numpy is a run-time-only dependency or if
>    it is needed at build time.

It is a built-time for the osgeo.gdal_array component that is for 
example used when using the osgeo.gdal.Dataset.ReadAsArray() method.

For generic purpose packages (unless you're very very tight on the 
binary footprint), I'd strongly suggest building the Python bindings 
with the numpy dependency, and make it a run-time one as well.


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