Re: [pcre-dev] More Windows-related/misc. tweaks

Top Page

Reply to this message
Author: Daniel Richard G.
To: pcre-dev
Subject: Re: [pcre-dev] More Windows-related/misc. tweaks
On Wed, 2007 Aug 01 10:34:51 +0100, Philip Hazel wrote:
> (Make sure you get the -RC2 and not -RC1 version - the latter was for an
> OP to test a bug fix.)
> If people can test this on Windows, in as many environments as possible,
> it would be good.

Sheri, this is for you :)

> I've tidied up the comments I added at the top and removed the
> PCRECPP_EXP_DATA_DEFN that I'd created (analagous to PCRE_EXP_DATA_DEFN)
> since it is not required.

The verbose comments are greatly appreciated. Also agree with removing the
_DATA_DEFN macro.

> > ==> pcre_maketables.c
> >
> > * Preprocessor directives must always have the "#" in column 1.
> No. Not since C was standardized in 1990. I made a fuss about this for
> the source of Exim, but I was persuaded to leave them in column 1 for
> PCRE (back in 1998 or thereabouts) because it is compiled on many
> different compilers, some of which were still in the dark, pre-standard
> ages back then. A decade later, I wouldn't be surprised if some still
> are...

My "must" is only a matter of practice, but I think it's a good rule.
Indented hash marks are such a trivial benefit, it makes you ask, "I'm
breaking compatibility with older systems for *this?*"

> > ==> CMakeLists.txt
> >
> > * Minor tweak, just restoring some tabs that got stripped.
> <rant>
> I hate tabs, I hate tabs, I hate tabs! :-) They always cause confusion,
> and personally, I never ever use them in files except for stupid
> programs such as "make" that insist on them. (And why? It could
> compatibly be extended to treat leading white space the same.)
> </rant>
> But I know nothing about CMake. Perhaps it needs them too. So I have
> restored them as per your patch.

I understand where you're coming from. CMake doesn't care about tabs versus
spaces, but given that the rest of the file uses tabs, I just wanted the

On Wed, 2007 Aug 01 11:01:41 +0100, Philip Hazel wrote:
> I'm slighly uneasy about the use of <pcre.h> instead of "pcre.h" in
> various #includes, because it relies on the presence of -I. on the
> compile line. I know that autoconf takes care of this automatically, but
> when people are compiling PCRE "by hand" - and some do: I had a message
> only a week or so ago from someone who built it on Windows without using
> ./configure etc - they may get caught. I have, nevertheless, left
> <pcre.h> as it is, and added a comment to NON-UNIX-USE explaining that
> -I. should always be used.

My view there is, if a source file is making use of PCRE's public
interface, then it is really no different from any other third-party app or
library doing the same. (This gets muddled somewhat if pcre_internal.h
becomes involved, but you get the idea.)

Personally, I think #include<> and -I... give more predictable behavior, as
the search locations are made explicit. This can be helpful in complicated
situations like an out-of-source-tree build.


NAME   = Daniel Richard G.       ##  Remember, skunks       _\|/_  meef?
EMAIL1 = skunk@???        ##  don't smell bad---    (/o|o\) /
EMAIL2 = skunk@???      ##  it's the people who   < (^),>
WWW    = http://www.******.org/  ##  annoy them that do!    /   \
(****** = site not yet online)