On Wed, 2007 Aug 01 10:34:51 +0100, Philip Hazel wrote:
>
> ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/Testing/pcre-7.3-RC2.tar.gz
> ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/Testing/pcre-7.3-RC2.tar.bz2
> ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/Testing/pcre-7.3-RC2.zip
>
> (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
consistency.
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.
--Daniel
--
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)
