Autor: ph10 Fecha: A: Daniel Richard G. Cc: pcre-dev Asunto: Re: [pcre-dev] [PATCH] PCRE2 on Windows
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.