On Thu, 2018 Jun 21 17:17+0100, ph10@??? wrote:
>
> > * Currently, the generic pcre2.h header (under src/) in the source
> > tree is used instead of the generated pcre2.h in the build tree.
> > This is due to the use of #include"pcre2.h" instead of
> > #include<pcre2.h>. Would it be all right to change all instances
> > of the former to the latter in the PCRE2 source?
>
> I have patched both configure.ac and CMakeLists.txt so that they
> delete pcre2.h and config.h from the source tree before doing their
> thing. This should solve this issue if you build in a non-source
> directory after downloading from the repo or indeed if you build in a
> different directory after previously configuring in the source
> directory. (This has caught me in the past when testing.)
I'm afraid this approach does not handle the case of a read-only source
tree, which a proper out-of-source tree build needs to support.
All that should be required, however, is to adjust the #include paths
and use #include<> ubiquitously. I'm still experimenting with this (it's
a lot less straightforward with CMake than I'd like) but I should have a
patch ready before long.
The issue of having previously configured in the source tree is the
original motivation why config.h should always be #included with <...>
instead of "...". From the Autoconf docs:
To provide for VPATH builds, remember to pass the C compiler a -I.
option (or -I..; whichever directory contains config.h). Even if you
use '#include "config.h"', the preprocessor searches only the
directory of the currently read file, i.e., the source directory,
not the build directory.
With the appropriate -I option, you can use '#include <config.h>'.
Actually, it's a good habit to use it, because in the rare case when
the source directory contains another config.h, the build directory
should be searched first.
-- https://www.gnu.org/software/autoconf/manual/autoconf-2.66/html_node/Configuration-Headers.html
> > * I am seeing some errors from the French-locale test on an older
> > Solaris system, which has fr_CA. I'm not quite sure how to
> > diagnose the problem. Would you be able to make heads or tails of
> > it if I posted the output?
>
> You can always try me...
:)
--Daniel
--
Daniel Richard G. || skunk@???
My ASCII-art .sig got a bad case of Times New Roman.
