[Top][All Lists]

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

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

From: Sergey Poznyakoff
Subject: [Bug-gnulib] Re: [Bug-tar] Re: argp-help.c patch for GNU tar; any more thoughts on uClibc getopt?
Date: Thu, 12 Aug 2004 20:57:55 +0300

Paul Eggert <address@hidden> wrote:

> As far as I know, only "tar" uses the gnulib argp module now.  I'm not
> sure why.

Not quite so. Both GNU Mailutils and GNU Radius, which I maintain, use it
too. And more than probable, paxutils will be using it too. I'm not
sure about GNU anubis yet, but I guess that in the long run it, too,
will switch to argp.

> Can you please briefly explain why argp is nice, and why you decided not to
> use it anyway?

First of all because it allows you to consistently represent the options
and their doc strings. The usual problem when using getopt/getopt_long
is that when you add a new option to optstring you often forget to
add an appropriate documentation string. With argp it is impossible,
you just have to add the docstring when you are adding the new option.

It is not so noticeable when your project has only 10-20 options. But
when it has 178 of then (as tar does), it becomes quite important.

Another feature is very important for projects that produce lots
of binaries (such as GNU Mailutils, Radius or Anubis). For such
projects, argp provides a way to represent options, common for
several programs in a way similar to subroutines in any high-level
programming language. For example, maintaining mailutils (which
generates more than 50 binaries, sharing the same subset of options)
without argp would be a real nightmare.

Last notice, in mailutils and radius we use AC_REPLACE
if we don't find argp in our libc.


reply via email to

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