Bruno Haible wrote: > Sam Steingold wrote: >> If I prepend -I$(srcdir)/gllib to CPPFLAFS, then >> >> #include <regex.h> >> >> will read the gnulib header, not the system header. > > Yes. > >> How can you be sure that this will not lead to any problems given that >> the libgnu.a does _not_ include regex.o? > > Because regex.m4 guarantees that. It tests for re_compile_pattern, and > only glibc systems have this function (including BeOS, which counts as > a glibc from ca. 1998). We are relying on the fact that glibc will maintain > backward compatibility for regex, like it did even when the regex code was > completely rewritten by Isamu Hasegawa. > >> If course, you can claim that, if gnulib regex.h were incompatible with >> the system one, then configure would have detected that and included >> gnulib regex in libgnu.a. > > Exactly. > >> In that case, why the file fnmatch.in.h not called fnmatch.h? > > If gnulib would only offer the 'fnmatch-gnu' module, this would make sense. > But it also offers the 'fnmatch' module, which does not insist on a GNU > like implementation of fnmatch(). > >> At any rate, if gnulib regex is included in libgnu.a, then regex.h >> should be copied (or linked) to $(builddir) or $(builddir)/gllib. >> The current situation is clearly wrong: regex is the only gnulib package >> which requires prepending -I$(srcdir)/gllib to CPPFLAFS! > > It is the package's responsibility to be consistent about $(builddir) > vs. $(srcdir). Don't use > -I$(srcdir)/gllib > or > -I$(builddir)/gllib > in isolation. Always use > -I$(builddir)/gllib -I$(srcdir)/gllib > so that -I options that come before it take precedence, -I options that come > after have lower precedence, and files in $(builddir)/gllib hide possible > (accidentally leftover) files in $(srcdir)/gllib. > > This is something that IMO ought to be mentioned in the Autoconf manual. > I have seen many GNU packages do this wrong. What do you think (Paul, > Eric, Jim, Ralf)?
Good point. I know I've gotten it wrong a few times.