popt

[Havoc Pennington <hp redhat com>]

Hi,

Investigating the g-ification of popt, there are a number of problems:

 - a bunch of #define constants, since we don't want to include
   popt.h you'd have to cut-and-paste their actual values, then 
   keep them in sync with the underlying popt stuff
 
 - uses gettext because it has some messages; glib doesn't
   have any messages right now, does it? So this would be 
   a new dependency
 
 - has error reporting; we still lack a standard glib error
   reporting setup

 - some functions return allocated memory not done with g_malloc();
   this means copying their returns, resulting in some sort of 
   inefficiency. Of course plain malloc() is used internally by popt,
   but that should be relatively OK

 - some of the stuff is not Windows-portable I don't think; in
   particular there seems to be some popt feature that involves
   exec()'ing a program. I don't know what the feature is exactly.

 - for language bindings, copy/free or ref/unref functions are likely
   needed on poptContext

 - poptPrintHelp and poptPrintUsage take a FILE*, which is not 
   acceptable; these should be "char * poptGetHelpString()" instead,
   so they are both more flexible and don't require including
   stdio.h

 - I guess the static structs are evil for language bindings (though 
   this may be a case comparable to GList, where language bindings
   will generally use the language-native facility instead of 
   wrapping glib, for example in Perl or Python you'd use the builtin
   getopt module)

Thoughts? Maybe we should fork off the codebase? That sort of sucks on
one hand, but on the other hand it's only 600 lines of code.

Havoc