RPM Community Forums

Mailing List Message of <popt-devel>

Handling 1-of-N mutually exclusive options within popt

From: Jeff Johnson <n3npq@mac.com>
Date: Fri 02 May 2008 - 19:19:46 CEST
Message-Id: <25377C03-1B5C-4FC1-A30D-ADFDF322CB3A@mac.com>
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
Received on Fri May 2 19:20:31 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.