Thomas,
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.
Yes, backward compatibility is an obvious requirement. That said, it would not be fully backwards compatible in the situations where users currently misuse the official synopsis, and typically when they repeat an argument that is supposed to not be repeatable. Currently depending on the argument and utility, they might potentially get an error, or the first occurrence will be used, or the last occurrence will be used (most often this last case). With a standard argument parser, this will be rejected with an explicit error message. This is actually what triggered me to consider using a dedicated mechanism for argument parsing.
Backward compatibility for nominal cases will be tricky in some situations. For example I see that ogrinfo supports a weird syntax like "-geom=NO" that p-ranav/argparse cannot support out of the box (it supports ["-geom", "NO"], and if a dash dash alias is also declared, ["--geom", "NO"] or ["--geom=NO"]). So for those hopefully rare cases, one will have to pre-process argv[] before passing to p-ranav/argparse so that is sees 2 separate argv[] values ["-geom", "NO"] instead to work properly.
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.
That's kind of orthogonal. We can support both with the logic: if the argv[i] value after "--config" has an equal sign in it, assume it is a key=value pair (none of our valid config options should have an equal sign in the key!). Otherwise assume argv[i] is the key and argv[i+1] is the value.
-- http://www.spatialys.com My software is free, but my time generally not. _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
