[gdal-dev] Using a "standard" argument parser for command line utilities?

[thomas bonfort]

Hi Even,
my number 1 requirement would be that the rewrite not cause any backwards
compatibility issues compared to today's argument handling. I suspect many
users are calling the gdal utilities through scripts and it would be a pain
to have to update those when upgrading gdal.

a nice to have enhancement that could be added during this upgrade (which
actually could be incompatible with my previous point, although I don't see
any on the top of my head) would be to support "--config key=value"
alongside "--config key value" in order to align with e.g. creation options.

best regards,
TB

Le ven. 8 mars 2024, 16:41, Even Rouault via gdal-dev <
gdal-dev at lists.osgeo.org> a écrit :

> Hi,
>
> Our command line C++ utilities use ad-hoc manual parsing, which means that:
>
> -  the usage message must be manually composed,
>
> -  you must take care to check that there are enough remaining arguments
> for the ones that take value to avoid out-of-bounds accesses (tests like
> argc + 1 < argn)
>
> - detection for duplicated arguments when only a single occurrence is
> allowed must be manually done, nd thus is often not done, confusing users,
> cf https://github.com/OSGeo/gdal/issues/9415
>
> - etc.
>
> I've come across https://github.com/p-ranav/argparse which fit all my
> requirements at first sight: compatible with our C++ requirements (C++17),
> MIT license, easily usable (single header), well documented, and enough
> feature-full. From a quick testing, it seems to work well. It looks also as
> it has taken some inspiration from the Python argparse module.
>
> I'd be tempted to give that a try to retrofit our existing utilities
> (probably starting with the ones with the less options :-)). Opinions? I
> guess there must be a plethora of similar projects, due to the absence of a
> std::argparse module... At least I see it is in the list of (9)
> alternatives mentioned at
> https://en.cppreference.com/w/cpp/links/libs?source=post_page---------------------------#Configuration:Command_Line
>
> CLI11 looked like a candidate too, but reading
> https://github.com/CLIUtils/CLI11?tab=readme-ov-file#features-not-supported-by-this-library
> "There are some other possible "features" that are intentionally not
> supported by this library:... Non-standard variations on syntax, like
> -long options. This is non-standard and should be avoided, so that is
> enforced by this library." . Fair enough, but we use that extensively in
> GDAL.
>
> Even
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240308/19e31bf4/attachment-0001.htm>