On 6/5/2010 10:55 AM, Jeff Johnson wrote:
> Note that a opaque (*help_transform) pluggable callback
> is what I propose ... no way do I want to see POPT start
> acquiring heavyweight linkages like -lxml2/-lexpat/-lsyck/-lwhatever.
> But almost certainly a reasonable API could be added so that
> --help transforms, with some reasonably simple (like the existing
> --help CLI display) transform vectors within -lpopt explicitly.
Actually I really like this idea. This would effectively introduce what
could be a plugin architecture for popt. Ideally this should be done
in a way where someone could create say an XML output and release a
separate library called popt_help_xml or something.
One of the concepts I've been playing around with is having the help
system double as a mechanism for programs to figure out what options
other programs have.
For example, it seems common place these days to write GUI shells on top
of command-line utilities. However, it's difficult to know what exact
parameters are available for a specific build without a run-and-test
So this mechanism would allow someone intrepid developer (or perhaps GUI
framework people like gnome/kde) to establish a standard for doing this
sort of thing.
The plugin/callback thing goes even further though. Even your
optionTable could support something like this. So in the case of your
auto-increment feature... this could actually be a "plugin" to popt,
allowing someone else (either the app developer) or a plugin author to
If done well, it's possible you'll start getting developers join you by
submitting plugins to the "default" installation.
Also, I don't know how others feel about this. But if it makes things
any easier (esp. if it makes it easier for the app developer), I'm
actually sort of okay with an external utility generating the options
table, and just allowing me to #include it in my source.
This has the potential of making the options table much cleaner/flexible
as it wouldn't be limited to c-style syntax.
Received on Mon Jun 7 20:25:33 2010