Even Rouault <even.roua...@spatialys.com> writes: >> and now have a test run that shows: >> >> = 312 failed, 6939 passed, 1489 skipped, 2 xfailed, 2 warnings in 746.96s >> (0:12:26) = >> >> which seems quite good overall. > > For a reasonably well setup environment, you should not get more than > a handful of failures. 312 definitely indicates something > wrong. Looking a bit at the logs you provide, they are explicit and
I meant that for a system where test issues were not yet debugged it didn't seem too bad. But we are rapidly reducing the count: now down to 20. > implicit complaints about GDAL_DATA not being set. I'm not sure if > you're running agains an installed GDAL lib (in which case, there's > something wrong in your build if it can't find /usr/share/gdal/ or > whatever similar dir in which GDAL data is installed), or if it a > in-build GDAL (in which case GDAL_DATA env var must be explicitly set > as done in setdevenv.sh) I am running against installed gdal, which was built with configure fairly normally. There's a lot of stuff in /usr/pkg/share/gdal. But, from trying to look at the dev env setup, I had a bad GDAL_DATA variable, and that was the problem. > A number of PROJ related failures can be caused by some grids being > missing. The 'conus' grid from > http://download.osgeo.org/proj/proj-datumgrid-1.8.tar.gz (there might > be others from that package. at least this is the one used for our CI) > must in particular be installed in /usr/share/proj (or > 'us_noaa_conus.tif' in PROJ 7 or later) OK - I have the grids intalled, but it is interesting to note that proj tests require them not to be installed while gdal tests require them to be installed. > It is possible to get a few PROJ related failures from time to time > given which version you use. Our CI covers a number of versions, but > not all obviously. I would hope 6.3.2 is still on the ok list. Lots of systems are a bit behind. > Hum, I suspect you might hit a similar issue as the one for FreeBSD in > https://github.com/OSGeo/gdal/blob/a95e796f65b26379b0e5c699bacef29f7684f79f/gdal/gcore/gdalopeninfo.cpp#L216 > where fopen("/some/dir", "rb") succeeds. Separate reply coming about this. Thanks very much for the pointer, which saved me a really long time looking into this. New test log at http://www.lexort.com/GDAL/ Looks like a lot of this the rtree module in sqlite3, which seems to think telling you to go back and rebuild something with different non-default options is a reasonable approach :-( I had not previously grasped that rtree was required, and configure seems not to test for it. Or perhaps it's not required and the tests should skip? But it looks like adjusting sqlite to have rtree will resolve more than half the remaining errors. (Thus, the test suite is being highly useful.)
signature.asc
Description: PGP signature
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev