<div dir="auto">Hi Even,<div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">best regards,</div><div dir="auto">TB</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 8 mars 2024, 16:41, Even Rouault via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div>
<p>Hi,</p>
<p>Our command line C++ utilities use ad-hoc manual parsing, which
means that:</p>
<p>- the usage message must be manually composed, </p>
<p>- 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) </p>
<p>- detection for duplicated arguments when only a single
occurrence is allowed must be manually done, nd thus is often not
done, confusing users, cf
<a href="https://github.com/OSGeo/gdal/issues/9415" target="_blank" rel="noreferrer">https://github.com/OSGeo/gdal/issues/9415</a></p>
<p>- etc.<br>
</p>
<p>I've come across <a href="https://github.com/p-ranav/argparse" target="_blank" rel="noreferrer">https://github.com/p-ranav/argparse</a> 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.<br>
</p>
<p>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
<a href="https://en.cppreference.com/w/cpp/links/libs?source=post_page---------------------------#Configuration:Command_Line" target="_blank" rel="noreferrer">https://en.cppreference.com/w/cpp/links/libs?source=post_page---------------------------#Configuration:Command_Line</a></p>
<p>CLI11 looked like a candidate too, but reading
<a href="https://github.com/CLIUtils/CLI11?tab=readme-ov-file#features-not-supported-by-this-library" target="_blank" rel="noreferrer">https://github.com/CLIUtils/CLI11?tab=readme-ov-file#features-not-supported-by-this-library</a>
"There are some other possible "features" that are intentionally
not supported by
this library:... Non-standard variations on syntax, like <code>-long</code>
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.<br>
</p>
<p>Even<br>
</p>
<pre cols="72">--
<a href="http://www.spatialys.com" target="_blank" rel="noreferrer">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</div>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank" rel="noreferrer">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>