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

[Charles Levert]

This is a problem I thought was limited to
"regex.h", but it may be more generalized after
all.  I'll start the discussion on bug-grep;
we'll see if it needs to be moved elsewhere as
it goes.

If a user configures with

   --with-included-foo=yes

the problem I want to highlight doesn't manifest
itself.

If, on the other hand, the user configures with

   --with-included-foo=no

or

   --without-included-foo

(whatever the supported configure option is),
then the included "foo.c" (or more source files,
whatever) will not be compiled, nor linked with
the program.  The installed system version will
be used instead.

However, which "foo.h" will be included for
compiling the program's code in this case?
I would assume that the installed system version
of it would be the right one to use, since it
goes with what will be linked against.

But that's not what always seems to happen.
The grep-package-included "foo.h" is used in
conjunction with the system's "foo.c".

For GNU grep, this is relevant for

   --with-included-gettext
   --with-included-getopt
   --with-included-regex

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?
(The --with-included-getopt configure
option seems to not be a gnulib thing, but a
package-specific one.)

It has no equivalent "regex_.h" for "regex.h".
Does it need one we could use?
Should we for the moment move (an updated version
of) "regex.h" to "regex_.h" in grep's CVS?


If you are familiar with gnulib, please help
clarify the situation.