} Please test, inspect, criticize in as many ways as you can. There
Well, I tried running 'configure' and 'make' and 'make check' on my
own machine, and it worked great. So I'm happy with it. :-)
The only 'issue' I got with the test was this:
< Failed: this version of PCRE is not compiled with PCRE_UTF8 support at offset 0
I think UTF8 has traditionally been turned off by default, right? So
that's not a regression. I tried again with ./configure --enable-utf8
and all tests continued to pass.
} 2. I think we have an issue with cross-compiling. The old build
Hmm, that's one of the things autotools is supposed to take care of
automatically. Not that I know how. :-) I've got a cross-compiler
handy on my machine, so I gave it a try:
./configure --host=powerpc-603-linux-gnu
You're absolutely right there's a problem: it compiled dftables for
the powerpc, and was then unable to run it.
Looking through the autoconf and automake info pages, and the web, I
couldn't find a good answer to this. In fact, it doesn't even look
like configure looks for a local compiler when cross compiling; it
only looks for a cross-compiler.
In fact, it sounds like we need to audit the autoconf features we *do*
use, to make sure they work correctly in a cross-compiling world.
It's easy to imagine they don't all -- for instance, we check to see
if we can use "long long" in the pcrecpp headers, but just because we
can on the build machine doesn't mean we'll be able to on the host
machine.
But a brief glance through autoconf.ac didn't show up anything that
seemed to me like it would be a problem in practice.
As for dftables, I admit I don't use any locale but C, but can't speak
to people who actually live in a place where a different charset is
the default. I'd like to believe that everyone has moved towards
unicode/utf8, but I don't know if it's true or not.
} 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.
Another choice would be to rewrite dftables, in say, perl. :-) Not
that I'm recommending that course of action...
My bias is (2), at lesat for this release, so we don't change too many
things at once. But if we can't figure out an easy way to do it, then
(1) sounds good; I think it's the right long-term direction in any
case.
} ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/Contrib
I looked through the existing c++ wrappers before we offered our own,
and I think most of that functionality is subsumed by what we have
now. I don't think much functionality would be lost by removing them.
I can't speak to the other files, which I haven't looked at.
craig
