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