Jim Blandy wrote:
>
> Matthew Braithwaite wrote:
> > Now, Bruce says that Autoopt can easily be bundled into other
> > software. If there is no impediment to putting it in the SVN
> > distribution, as opposed to requiring it as an external library, I
> > have no worries about using it.
>
> There's also the barrier-to-entry cost of every "tool": people have to
> learn it before they can hack on our code. For example, autoconf /
> automake / libtool make our build process harder to hack.
>
> To me, it seems easy enough to do a good job of argument parsing in
> straight C code, or using apr_getopt{,_long}, that the "tool" cost ---
> even of a good tool --- probably isn't worth it.
>
> Bruce is right that people are often sloppy, but I see folks putting a
> good amount of thought into the design, so I don't think that'll be an
> issue here.
If you tried to read and understand all the reference documentation
for AutoOpts, I am certain you would find the entry barrier very
high, indeed. OTOH, if you just read and play with the "quick start"
stuff, I would find it surprising if you found the barrier high.
But, maybe I am wrong. The simple stuff *is* simple, as long as
it is not overexplained. So, Jim, please tell me: what seems difficult?
Maybe I can explain it less. :-) Thank you!
WRT "We won't be sloppy because we're working carefully": let me just
say that having the available options coded into the svn.texi file,
and the svn.1 file, and the multiple parsing loops (for each subcommand),
and the envrionment variable parsing, and the RC file parsing,
and so-on, *will* be a problem. When I was finally done with the
rework of GCC's fixincludes, the result was far more comprehensible
than the old cruft. I am certain the same will be true of option
processing for SVN.
Received on Sat Oct 21 14:36:12 2006