Re: Tabular command processing sans AutoOpts

Bruce Korb <bkorb@cruzio.com> writes:
> Karl> A detail: the names `tOptions', `t_cmd_desc', and `t_cl_cmd_proc'
> Karl> would need to have the "svn_cl__" prefix, for the reasons described
> in
> Karl> the top-level HACKING file.
>
> Would that apply to te_command, too? ;-)
> "tOptions" will ultimately be externally defined.

I don't know. Read HACKING and ask if questions remain after that.

Re the table: I think it's worse to have lots of empty C files sitting
around unused for a long time, than to have to tweak four locations
when adding a new command. After all, if one fails to tweak any of
the four locations, things either won't work right immediately, or the
lack of documentation will be noticed eventually (and with this list
doing eyeball patrol, it will be noticed sooner rather than later).

You asked Greg H:
> You *are* talking about re-inventing everything. Why?
> There are several option parsers out there already. Is each one
> so deficient that a new one is needed? Why?

Answer (which has already been discussed on this list):

The getopts_long interface is one familiar to many programmers, but we
don't know of a free implementation whose copyright permits it to be
placed in Subversion or APR. Hence, Greg has volunteered to implement
one.

If you do know of such an implementation, please point the way.

-K
Received on Sat Oct 21 14:36:14 2006