On Wed, Oct 18, 2000 at 04:17:57PM -0400, Greg Hudson wrote:
> > But seriously, I think we should (eventually if not immediately)
> > support the more flexible GNU way, because it does result in
> > increased convenience for the user, and is no more ambiguous than
> > the other way.
>
> Well, there are some implementation issues:
>
> * gnu getopt supports the more flexible way, but apr_getopt()
> does not (and the BSD implementation does not). I don't
> know how the APR people would feel about making apr_getopt()
> more flexible. apr_getopt_long() needs to be consistent
> with apr_getopt().
If the code is provided, then I'll check it in! :-) I don't believe there
would be any objections. [presuming it isn't a massive implementation
across a dozen files]
> Of course, this point is moot if we use autoopt. I'm not
> quite sure where that decision lies; Bruce Korb and company
> seem very gung-ho about it,
I'm not sure that Bruce ever made a disclaimer: he is the author of AutoOpt.
So yes... I now understand his gung-ho-ness, and his response about
"notifying the author".
> but several of the people who have
> previously done work on Subversion expressed reservations
> about bringing in a separate external tool for such a small
> problem. If we do use autoopt, then we can only support the
> more flexible approach if autoopt does.
I'm -0 on bringing in AutoOpt. I'd much rather see our option performed
using getopts() [or its variants using whatever codebase we can]
Consider: why are we using Autoconf, Automake, and Libtool? Because the
tools are great? Don't make me laugh. No... we use them because *other*
people know them, and those others can then usefully contribute to our auto*
setup.
Why use getopts()? Because other people know them, and we can leverage that
group knowledge.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:11 2006