Re: --with-included-foo={yes,no} and which foo.h to use?

[Charles Levert]

Thanks for replying.  My understanding of this
is still not yet complete, so here it goes.


* On Tuesday 2005-06-14 at 22:06:43 -0700, Paul Eggert wrote:
> Charles Levert <address@hidden> writes:
> 
> > Does using gnulib solves the problem?
> > It seems to have a "getopt_.h" that only gets
> > copied to "getopt.h" in some circumstances.
> > Is its logic to identify those circumstances
> > right for our purposes?
> 
> Yes, that's right.

But if I understand "grep/configure.in" and
"gnulib/m4/getopt.m4" correctly, wouldn't it
be possible that (if both are combined), in the
--with-included-getopt=yes case on a system that
already has GNU getopt, the package-included
version will be compiled and linked (because of
"grep/configure.in") yet the system <getopt.h>
will be #included in the main program source
files (because it's recognized as being GNU
according to "gnulib/m4/getopt.m4" which won't
define GETOPT_H then)?

See my comment further below on my apprehensions
about mixing half system-provided, half
package-included.


> > It has no equivalent "regex_.h" for "regex.h".
> 
> I think that's because there's no system regex.h that anyone would
> want to use.  gnulib regex.h is unique.

A strictly-POSIX system <regex.h> would not do
(so --with-included-regex will in effect be
mandatory then), but what about a glibc-based
system?

For GNU grep's purposes, we need non-POSIX
constants such as RE_ICASE, and I can see those
in my "/usr/include/regex.h".  Assuming a system
with a satisfactorily recent glibc, we can avoid
code duplication (and have a smaller executable
before dynamic linking) by using its regex code.
(A distributor of a package-versions-coherent
GNU/Linux system would surely aim for that.)

I would then assume that the thing to do would
be to use the <regex.h> that comes with it,
just in case of, e.g., the same macro constant
names would be defined to different integer
values in different versions (or any other
slight incompatibilities).

Is there anything special in gnulib's "regex.h"
that's not in glibc's, such that we would
absolutely want to use gnulib's over glibc's?
(And if so, what is it?)