On Wed, 16 May 2018, Daniel Richard G. wrote: > > ... but would this not have the effect of including an *installed* > > version of pcre2.h from /usr/include instead of from the build or > > source trees? > > That won't be a problem, because an -I$(builddir)/src would be part of > the #includes. (Note that #include<> typically searches the list of -I > directories before looking in the system directories.)
... but we'd need "always" rather than "typically" wouldn't we. :-) CMake (on my Linux box) puts pcre2.h and config.h into the build directory directly, not into builddir/src. However, Autoconf does put them into buildir/src. BUT ... running "make -n" with CMake does show the commands with appropriate -I settings, so it does seem to do the right thing. > I've been building within the SVN tree, which has the file: I'm now wondering why it has the file? Perhaps some historical reason, but I see no reason why it should have it. It does, after all, have pcre2.h.generic which is identical. Perhaps I should remove pcre2.h from the SVN repo. > Removing it may solve the immediate issue, but the setup will remain > fragile to any errant file that is left under $(srcdir)/src/. I think > using <pcre.h> consistently, in addition to removing the file from SVN, > is the best solution. I *have* removed pcre2.h from the SVN repo. You are right about read-only source directories; I had overlooked that. Unfortunately rm -f barfs at a read-only file, so I have reversed that patch. I'm still unhappy about changing "" to <> because it seems to go against the presumption that <> is for system headers and "" is for headers local to the program. Philip -- Philip Hazel -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
