On Sun, 22 Jan 2012, Philip Hazel wrote:
> What I don't know is whether building PCRE under Windows using one of
> the standard methods (i.e. "configure" or "cmake") works. I rather
> suspect that it won't. *That* is why I think changes are needed.
I think this issue would hinder a Windows build only if that library
is built as a DLL. In a more conventional non-DLL build the resulting
".lib" would contain all the code and data that you'd expect to see in
a Unix build. Linking pcretest plus pcre_printint plus the library
would resolve the tables using the pcre_tables compilation that's in
the library. That's my guess anyway.
Tomorrow I hope to have time for some RC1 evaluation. If it's not in
the trunk yet then I'll use Zoltan's patch to see what happens.
I'm guessing it's already verified, and in any case equalizing the
PRIV() seems like a sure bet to circumvent what was encountered.
Adjusting just documentation or the code, I'm happy with either one.
This was tiny considering the extent of changes that must have been
required to enable the option of 16-bit data matching.
