A common paradigm when using CLI options is to select 1-of-N mutually exclusive

ATM, the burden of detecting "mutually exclusive" is up to the application, not popt.

There's room (if I'm careful) for adding bits (I *think* I can squeeze out 8 bits) for a "mutually exclusive" group identifier into the 32b argInfo field, and then implement "mutually exclusive" by running a counter
on the group options.

There are other reasons than "mutually exclusive" to add a group identifier. Consider filtering options in popt tables based on mode of execution, where some options should only be interpreted in a
specific mode of operation.

rpm has many examples of both "mutually exclusive" options, and per- mode options. Yes, there
are certainly application specific means to handle the usage cases.

My specific and immediate usage case is writing a "universal" compressor/decompressor
that handles gzip/bzip2/lzma/lzo and whatever else seems useful.

Note that legacy compatibility would be achieved by reserving group 0 to be always available.

Yet Another reason for adding option groups is feature parity with Newer! Better! Bestest! getopt_long()
processing as implemented in (iirc, I fergit where I saw) GNU tar/cpio.

(aside) My personal opinion of the GNU option grouping in tar/cpio was quietly disposed of in a barf bag. However, there are certainly other, possibly valid, certainly different, opinions around. I know only my own aesthetics.


73 de Jeff
POPT Library                                           http://rpm5.org
Developer Communication List                       popt-devel@rpm5.org

Reply via email to