[gdal-dev] get_cli_utility_path_internal

[Even Rouault]

Andrew,

obviously this code having essentially passed through the ages since 
2008, I don't remember all the details :-) I assume this was an attempt 
to pick up a binary that could be run and was part of the build tree, 
instead of a system gdalinfo/etc. binary, but this could likely be 
simplified by assuming that the PATH is set to have the path for the 
binaries of the GDAL build listed first. Running through ctest should 
already ensure this. Running directly with pytest, not necessarily, but 
developers are then supposed to correctly set their env (e.g  with 
scripts/setdevenv.sh on Unix), and CI configs should hopefully do that. 
If you were to change this, it would be nice though to check that the 
version reported by the utility matches the one of the Python bindings 
to detect potentially mismatches.

Even

Le 06/06/2024 à 23:05, Andrew Bell via gdal-dev a écrit :
> The function in the subject returns a path to a utility on which to 
> run a test. But in the process, it tries to run the utility itself. 
> This seems strange. In my case, the test itself failed, but the code 
> reported "Could not find {file}", which is incorrect. It also causes 
> the actual tests to get skipped, when they should fail.
>
> I can fix this, but I don't understand why there's an attempt to run a 
> utility in order to determine its path. I would think that checking 
> that the file exists would be sufficient (and this already occurs), 
> but I'm not privy to the history.
>
> -- 
> Andrew Bell
> andrew.bell.ia at gmail.com
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240606/cf8ff263/attachment.htm>