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.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
