On Thu, 2018 Jun 21 17:17+0100, p...@hermes.cam.ac.uk 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. || sk...@iskunk.org My ASCII-art .sig got a bad case of Times New Roman. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev