A common paradigm when using CLI options is to select 1-of-N mutually
exclusive
options.
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.
Opinions?
73 de Jeff
______________________________________________________________________
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
