Hi Andrew, > I'm trying to enable autotest so that I can easily verify changes I make to > GDAL. I'm having difficulty as my familiarity with the python environment > is limited. I don't think I want to install the swig bindings OVER the > current GDAL interface code that I may have in my system python > installation. I would think I could build the bindings, have the > associated .so's (or .dylib's) reference the GDAL build tree and install > the python modules/shared objects in a location I can invoke from autotest > by setting PYTHONPATH accordingly. > > This seems difficult to accomplish given the setup so it makes me think I'm > doing something wrong. Is there a standard (and easy) way to get tests > going on a local GDAL build tree that I'm missing?
In each of my GDAL trees, I have in gdal root (where you invoke ./configure) a setenv.sh script with the following content export PATH=$PWD/apps:$PATH export LD_LIBRARY_PATH=$PWD:$LD_LIBRARY_PATH export GDAL_DATA=$PWD/data export PYTHONPATH=$PWD/swig/python/build/lib.linux-x86_64-2.7 which I source. So that way I don't need to run "make install" This is for a --without-libtool build. For a libtool build, you need to modify to export PATH=$PWD/apps/.libs:$PATH export LD_LIBRARY_PATH=$PWD/.libs:$LD_LIBRARY_PATH > > P.S. - It seems strange to use python as a CI interface to a C/C++ > library. Is there a reason the test harness isn't in C/C++? Mateusz already answered on that. Writing Python tests is faster/easier than C/C++ ones. We/I tend to limit C/C++ written tests to part of the API not available through the Python API. Even -- Spatialys - Geospatial professional services http://www.spatialys.com
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
