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.
