Author: ph10 Date: To: Maël Hörz CC: pcre-dev Subject: Re: [pcre-dev] PCRE2 first Release Candidate
On Sat, 29 Nov 2014, Maël Hörz wrote:
> I noticed an issue so far with CMAKE under Windows and Visual Studio 2013:
>
> PCRE2_BUILD_PCRE2_8 = ON works, but switching on PCRE2_BUILD_PCRE2_16
> and PCRE2_BUILD_PCRE2_32, too, causes function prototype conflicts (same
> name exported/defined several times).
Can you post the errors? I have no access to any Windows systems, but
from the errors I might be able to work out what is going on. Better
still if you can post a fix. :-) [Or send it to me direct.]
> I also noticed that there is still an option PCRE2_SUPPORT_BSR_ANYCRLF
> that is separate from PCRE2_SUPPORT_UNICODE.
I will look into that.
> Isn't this inconsistent considering the following decision? (If you extend
> normal character classes to Unicode why not linebreaks, too? That it is
> disabled by default is a consistent default, though.)
> > 2. Note that --enable-utf and --enable-ucp have been amalgamated
> > into --enable-unicode, and this is now the default.
Making the building of Unicode support the default does not alter the
runtime defaults, which have not changed, and are non-Unicode.
> > PCRE2_BUILD_PCRE2_8 = ON works, but switching on PCRE2_BUILD_PCRE2_16
> > and PCRE2_BUILD_PCRE2_32, too, causes function prototype conflicts (same
> > name exported/defined several times).
> This only happens when BUILD_SHARED_LIBS is enabled.
Oh dear. That suggests it is tied up with the Windows way of handling
libraries, about which I know nothing. If you cannot help, perhaps
eventually another Windows user on this list will be able to sort this
out. I hope so.
