[Bug-gnulib] Re: final argp patch

[Simon Josefsson]

Paul Eggert <address@hidden> writes:

> Simon, this sort of Autoconf automation is already being done for
> alloca and for fnmatch.  Can you please look into doing it for argp
> too?

I had a feeling about this problem earlier, but I now realized it
fully: the ELIDE_CODE construct is forwards-compatible, whereas
Autoconf solution is not, as far as I understand.

Specifically: If glibc argp API change in a incompatible way, with the
ELIDE_CODE construct the gnu-version.h CPP variable is incremented.
So an application written for the old API, and shipping a ELIDE_CODE
argp, would detect this and use the argp that is shipped with the
application.  So it would work.

But if an application is written for argp 1 and glibc is changed in an
incompatible way, I cannot see any way the (old) argp code in gnulib
that is shipped with an application could detect this.  Instead, it
would likely just discover that glibc do support argp, and use it.
Which would fail since the application was written for version 1.

So the ELIDE_CODE construct is not just an optimization.

The option seem to be:

* ignore this problem.  I.e., no ELIDE_CODE and a argp.m4 in gnulib do
  AC_CHECK_FUNC(argp_parse) or something to find out if glibc support
  argp.  If glibc argp API ever change, all old applications using
  argp from gnulib will no longer work.

* add ELIDE_CODE.

* always compile argp in gnulib, no conditional checks.

Are there more options?  Do you understand my concern?  Any flaws in
the above?

I have only thought about this, not done any experiments, so I might
have missed something.

If my reasoning above is correct, it appears to me as if adding
ELIDE_CODE actually is the right thing, although I also agree it is
ugly.  Perhaps modularize the ELIDE_CODE idea somewhat would make it
less ugly.

Thanks.