bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-gnulib] Re: argp-help.c patch for GNU tar; any more thoughts on uCl


From: Simon Josefsson
Subject: [Bug-gnulib] Re: argp-help.c patch for GNU tar; any more thoughts on uClibc getopt?
Date: Thu, 12 Aug 2004 20:50:38 +0200
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)

Paul Eggert <address@hidden> writes:

> Simon Josefsson <address@hidden> writes:
>
>> I don't use argp any longer, though.
>
> Ouch.  You were the main proponent of argp in gnulib, if I recall
> correctly.  (I was counting on you to migrate the argp changes back
> into glibc.  :-)
>
> As far as I know, only "tar" uses the gnulib argp module now.  I'm not
> sure why.  And to be honest I'm not that familiar with argp.  Can you
> please briefly explain why argp is nice, and why you decided not to
> use it anyway?  Thanks.

For some reasons, see:
<http://lists.gnu.org/archive/html/bug-gnulib/2003-12/msg00005.html>
and my discussion on the gengetopt list:
<http://lists.gnu.org/archive/html/help-gengetopt/2003-06/msg00000.html>
where I actually initially wanted to move from gengetopt to argp.

However, the gengetopt people implemented support for everything I
complained about, while the libc people didn't respond to my patch, so
I stuck with gengetopt in libidn.  Later on, building on the
experience with gengetopt in libidn, and argp in other projects, I
eventually changed from argp to gengetopt in my other projects.

I don't have many technical problems with argp, except that the code
is unreadable.

The factor that probably made me change from argp to gengetopt was
that the glue code needed to use argp became large.  You need to
define an 'enum', a 'struct', a 'parse_opt' function that translate
enum codes into stuff you put in the struct.  My feelings were that
writing that code could be done by a robot, so I didn't want to.
Gengetopt is that robot, and write all that code, but, alas, don't use
argp for the actual implementation, but instead use getopt_long
directly.

As discussed in the second URL above, I believe the best solution (for
me) would be to use a description language, like gengetopt, and a tool
to generate code, which would invoke argp to deal with the actual
printing and parsing.

(For completeness, I probably have more technical problems with
gengetopt than argp: there is no gettext support, the description
language is inflexible, it doesn't handle multiple non-option
arguments, the code use weird acronyms and abbreviations for
variable/function names.)

Hope this helps,
Simon





reply via email to

[Prev in Thread] Current Thread [Next in Thread]