adding a new lib for more advanced argument parsing

[Alexander Best]

On Sun Sep 26 10, perryh at pluto.rain.com wrote:
> Alexander Best <arundel at freebsd.org> wrote:
> 
> > ... getopt(3) is clearly not suitable for handling such complex
> > options.  camcontrol.c even contains a whole paragraph about why
> > getopt(3) is considered not appropriate to handle camcontrol's
> > argument parsing requirements ...
> 
> > why not do a vendor import of popt 1.16 e.g.? are there license
> > restrictions?
> 
> AFAIK it is GPL; it was used in Red Hat Linux prior to the split
> into Fedora and RHEL (and may still be, for all I know).
> 
> > or maybe some other lib...
> 
> Dunno what-all may be available.
> 
> popt has its own set of limitations.  Check the archives from
> the RPM mailing list from around the time when RPM switched
> to popt, or perhaps it was when rpmbuild was split out into
> a separate executable, for the laundry list of issues they
> encountered in attempting to maintain compatibility at the
> command line level between what they had before and after.

oh i didn't know that. i thought it was superior to getopt() in every fashion.

also i'm not voting to completely get rid of getopt(), but merely to make it
easier for developers to handle complex options. i mean posix is fine and all,
but if they recommend using horses instead of cars shouldn't it be decided that
we need both: for comptaibility and performance?

cheers.
alex

-- 
a13x