Le lundi 12 septembre 2016 16:59:34, Poughon Victor a écrit : > Hi Even, > > This is a really cool and really impressive feature! > Calling Python code from C++ without development packages as a dependency > sounds like black magic to me.
No black magic. Just setting function pointers using dlopen() : https://github.com/OSGeo/gdal/blob/trunk/gdal/frmts/vrt/vrtderivedrasterband.cpp#L390 > Obviously Python symbols have to be there > at some point to execute Python code, so this is only usable from a binary > that happens to load them already (CPython, QGIS, etc.), correct? No, there are 2 modes: - GDAL is loaded after something else has already loaded python (so your CPython, QGIS) - GDAL cannot find any python symbols in the already available symbols of the process, in which case it wil try to load a few reasonable shared objects like "libpython2.7.so", etc... See https://github.com/OSGeo/gdal/blob/trunk/gdal/frmts/vrt/vrtderivedrasterband.cpp#L238 and below lines > But I'm confused because later you mention > incompatibilities issues between the CPython and Pypy API. GDAL's secret > sauce, I guess...? Nothing GDAL specific here. It is just that the way to embed PyPy from C is completely different from CPython : http://doc.pypy.org/en/latest/embedding.html vs https://docs.python.org/2/extending/embedding.html > I'm also curious why it's possible to use numba but no > pypy, which AFAIK are both python JITs? numba is "just" a CPython extension (a non-trivial one dragging llvmlite etc...), so once you support CPython, it comes for free to use it, provided you use the right import and function decorations in your python code. > And finally did you consider using > Cython (which claims pypy compatibility)? No, I didn't investigate that. Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
