[Sent to the pcre-dev list and a couple of people who I'm not sure are
on the list, but who have commented on PCRE.]
I have just put a first release candidate for 7.1 in
ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/Testing/pcre-7.1-RC1.tar.gz
ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/Testing/pcre-7.1-RC1.tar.bz2
ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/Testing/pcre-7.1-RC1.zip
There are also detached signatures in that directory, should you want to
check them.
As I mentioned on Friday, as well as the new build apparatus, I have
fixed some bugs and done other tidies, but there is no substantial
change to the actual code itself. The ChangeLog file has details of
changes. I have revised some of the building documentation.
Please test, inspect, criticize in as many ways as you can. There are
some specific issues that I would like people to comment on:
1. I would like to include more specific instructions about building
under Windows, but I lack the knowledge. Daniel, is your Cmake stuff
complete, or is there still more to do? In particular, could people
who know about Windows and Cygwin/MingW please take a look at the
NON-UNIX-USE file and tell me how to improve it.
2. I think we have an issue with cross-compiling. The old build system
allowed for CC_FOR_BUILD, CFLAGS_FOR_BUILD, etc, so as to use a
different compiler and/or compiler options for the dftables.c source,
which has to be compiled and run at build time. I believe that this
may have got lost in the transition to the new world. See the
comments on cross-compiling in README; I suspect they no longer work.
However, it seems to me that perhaps we can bypass this problem
altogether. The idea of compiling and running dftables at build time
is to obtain a default set of character tables based on the current
locale. Is this really very useful? Nowadays, the use of locales is
going out of fashion with the rise of Unicode, and given the
increasing international nature of everything, it might make sense to
have a fixed default locale for PCRE (the "C" locale, presumably).
This could be done by distributing the pcre_chartables.c file instead
of generating it dynamically. (This does not prevent callers of
PCRE from providing alternative tables at run time if they want to.)
Having a fixed set of default tables would also get round the
occasional problem in the tests that is caused by somebody building
PCRE in an unusual locale.
The choice seems to be (1) Use fixed default tables, as suggested,
which is easy, or (2) Find a way of modifying the new build system so
that CC_FOR_BUILD etc can be specified, which sounds more difficult
to me.
Comments? I'm tempted to go for (1).
3. The Contrib directory on the PCRE ftp site
ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/Contrib
contains a lot of stuff that has accumulated over the years, much of
it to do with compiling PCRE on Windows and with C++ wrappers of
varying complexity that pre-date Google's. Is it useful to keep any
of this? There's no harm in leaving it online, but if it is no longer
applicable, perhaps it should be removed to avoid confusing people.
4. I have written a document for maintainers, which I have committed to
the file maint/README in the svn repository. As well as some notes on
what I do when creating a PCRE release, I have also included the PCRE
"ideas list" there, just in case anybody wants to comment.
Feedback awaited...
Philip
--
Philip Hazel, University of Cambridge Computing Service.
