bug-gnulib
[Top][All Lists]
Advanced

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

[Bug-gnulib] Re: final argp patch


From: Paul Eggert
Subject: [Bug-gnulib] Re: final argp patch
Date: 04 Oct 2003 21:58:37 -0700
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

Simon Josefsson <address@hidden> writes:

> > #include <gnu-versions.h>
> > #if _GNU_ARGP_INTERFACE_VERSION < 1
> >   #error "system argp interface is too old"
> > #endif
> >
> > If it doesn't compile, then either the system lacks argp, or its
> > interface is too old.
> 
> Ah, right.  Except there is no _GNU_ARGP_INTERFACE_VERSION in glibc
> now.

In theory that's OK.  A preprocessor symbol that is not defined
evaluates to zero.  So the test program won't compile, and GNU
applications will build their own argp, and we will be no worse off
than we already are.  Once glibc has _GNU_ARGP_INTERFACE_VERSION, the
optimizations will start to be enabled.

However, I see your point.  Perhaps it'd be better just to check for
argp.h and then behave as fnmatch.m4 etc. do.  This would generate
smaller apps with the current glibc, without having to worry about
letting _GNU_ARGP_INTERFACE_VERSION propagate to installed glibc
versions.

> Do you think adding it to glibc, without a ELIDE_CODE patch as well,
> is the right thing?

Two things:

(1) It sounds like a reasonable thing to do, since it's the existing
    mechanism already used by obstack, regex, glob, and getopt.

(2) However, nobody uses that mechanism as far as I know.  Everybody
    uses behavior tests instead of version-number tests.  This is
    because the version-number tests are less reliable.

Consistency argues that either _GNU_ARGP_INTERFACE_VERSION should be
added to gnu-versions.h, or gnu-versions.h should be removed.  Most
likely the latter would be more acceptable to the other glibc
maintainers.  I guess gnulib shouldn't care either way.




reply via email to

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