Greg Hudson wrote:
Greg>
Greg> > This patch will also add a bazillion stubs:
Greg> > [...]
Greg> > that were all mechanically generated.
Karl wrote:
Karl> I'd feel a little funny about adding lots of C stub files to the
Karl> command-line client source directory, without knowing more about why.
Either we use mechanically generated text, or we don't. :-)
If we do, then there is little gain adding the stubs because
we can create the glue as the modules are added. If we don't,
then the Makefile.am and the command dispatch tables must all
be maintained by hand. It is a nuisance. [aside: I expect
the generated stubs to be elaborated by hand and never regenerated.]
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.
Karl> Sorry, I'm not meaning to make this Pick On Bruce Day
Well, I'm trying to stir the pot a bit. Bruce prefers criticism
to silence. :-)
Karl> -- some sort of command table looks like the right way to go,
Karl> I just don't understand the motivation behind all parts
Karl> of this patch.
I just want to build the dispatch tables and callout routines once.
Minimize the number of times the four different tables need tweaking:
1. Makefile.am(svn_SOURCES)
2. svn_cl__te_command
3. svn_cl__cmd_proc command list
4. cmd_table
Do it once. Let it be mostly done. :-)
Greg> I don't like using mechanically generated C source code when it's
Greg> avoidable. It complicates the build system and is generally ugly.
This is a build system problem that is painfully but gradually being
addressed. Since I use generated source a fair amount, I have worked
out the kinks for my projects. In any event, nothing in this patch
is intended to be regenerated. It was a one-time event.
Greg> I've thought about this issue and I can't think of any compelling
Greg> reason why any aspect of a table-driven argument handler shouldn't
Greg> just be a library. All of the tabular information you need easily
Greg> fits into an array of C structures a la the array passed to
Greg> getopt_long(). Even if you want your library to handle usage
messages
Greg> and rc option processing, the same array of structures will do just
Greg> fine for those library functions as well.
This must be a AutoOpts vs. getopt_long argument:
1. You cannot use the struct to generate man pages or info sections.
2. You cannot enhance the struct without invalidating old code
3. As the struct becomes more comprehensive (read: complex),
it becomes more difficult to initialize correctly
4. Incorporating globally-standard and project-standard options
is non-trivial
5. You have to write your own processing loop, even though it is
not any different than the processing loops of a million other
programs. (unless you are talking about re-inventing everthing)
6. Some items cannot be initialized in a single table (e.g. the
declarations of callback procedures). Consequently, using pure
C structures will *force* you to have option information spread
around.
Greg> (I apologize for not having implemented apr_getopt_long after quite
Greg> some time; I hope to do it soon. But that's only tangentially
Greg> related.)
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?
Received on Sat Oct 21 14:36:14 2006