Re: [pcre-dev] Kudos on PCRE 7.2...

I currently don't have access to my usual workstation (it is currently
in boxes), but I'll do my best.

On Wed, 2007 Aug 29 09:41:00 +0100, Philip Hazel wrote:
>
> > Yes, the instance I mention above was switched back to the "" form - but the
> > former SINGLE #include "config.h" in pcre_internal.h has now apparently been
> > replaced by 22 #include <config.h> uses across the whole project.
>
> If you look at the mailing list archives you'll see discussion about
> this. I questioned it, but Daniel argued that it was the "standard" and
> recommended way to go, to ensure that #include config.h appeared *at
> the very start* of every code module, before anything else that might be
> relying on what was set in the config. We also had the < vs "
> discussion; I must confess to not being totally convinced, and also I
> guess it's my fault for not noticing the new #includes use < rather than
> ".
>
> I suspect I can't win on this, though. Perhaps Robert and Daniel can
> discuss on the list and come to some conclusion. I imagine it's all to
> do with auto vs manual building, and also building in other (non-source)
> directories comes into it as well. This is an area I know little about.

The Autoconf docs explicitly recommend < instead of " when #including
config.h, to allow building outside of a source tree that has already
been configured from an in-tree build (i.e. config.h already exists in
the source tree).

> Having said that, the change to the build system for 7.1 was inended
> to "regularize" things so that it was straightforward to build on
> Windows. As I know nothing about Windows, I am reliant on what other
> people tell me should be done. I think Daniel, if he joins in this
> thread, will extol the virtues of CMake for use on Windows.

Muchly so. There are still some kinks in the CMake build system (e.g. no
COFF metadata gets added yet), but in general, these are failings of
my/our CMake program code, and not CMake itself.

(If there are significant issues with the way CMake builds things, of
course I'll look at that.)

> > Each of the newly added '#include <config.h>' is "protected" by a '#ifdef
> > HAVE_CONFIG_H' - which presumably should be '#ifndef'?
>
> I don't think so... Daniel? Is this a valid comment? Everything works
> fine on Unix, and others seem to have used the RCs on Windows.

No, "#ifdef HAVE_CONFIG_H" is exactly what it should be. The build
system gets to decide whether it wants to use multiple -Dfoo=bar
directives on the command line, or a config header, and passes
-DHAVE_CONFIG_H (as the sole -D directive) in the latter case.

> > Not to mention the '# ifdef...' inside the '#ifndef DFTABLES' in
> > pcre_maketables.c...

Likewise. That bit is a special case, as pcre_maketables.c is compiled
both as a standalone module, and also as part of dftables.c (where it is
#included directly into the file).


--Daniel