RPM Community Forums

Mailing List Message of <popt-devel>

Re: Teaching POPT 2.0 about HTML/XML/YAML?

From: Jeff Johnson <n3npq@mac.com>
Date: Mon 07 Jun 2010 - 20:44:31 CEST
Message-id: <DF15EFDE-288F-406A-A835-B5961FC78CCA@mac.com>

On Jun 7, 2010, at 2:24 PM, Danny Sung wrote:

> 
> 
> 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.
> 

But the issue becomes
	Where do I get an additional "void *" from?
in order to do
	rc = (*callback) (..., callback_context);

The existing --help callbacks are per-table, not per-item, and
so that forces the insanity of 1 option per-table in order to
use. There are other, --help i18n insanities, with the exisiting
POPT 1.0 callbacks too.

> 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 operation.
> 
> 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 write.
> 
> 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.
> 

Generating the options table form *WHAT*? If you have well defined markup
from which a popt table can be generated, I'd rather see that utility
internal to POPT itself, not external where noone else benefits from
its existence.

Nothing in the previous statement precludes anyone from generating POPT
tables however they wish externally. Just internal can/will be maintained
and tested and ... whatever else is needed.

ATM, I know of no well-defined markup, nor any attempt to automatically
generate POPT tables using an external utility.

Translation:

	Show me the code.
Received on Mon Jun 7 20:45:11 2010
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.