On 11/22/11 2:11 AM, "ext [email protected]" <[email protected]> wrote:
> >On 22/11/2011, at 2:45 AM, Giuseppe D'Angelo wrote: > >> On 16 November 2011 16:08, <[email protected]> wrote: >>> Yes, the implementation based on UTF-8 vs UTF-16 version of PCRE would >>> only differ on two lines, the UTF-16 -> UTF-8 and UTF-8 > UTF-16 >>> conversion before and after the matching. >>> >>> I suggest we get started on this with the current version of PCRE, and >>> hope that entices the PCRE team to work on a proper UTF-16 >>>implementation. >>> >>> Anyone interesting in jumping on this task? >> >> I can volunteer some time :) >> >> But first: do we all (esp. Thiago, Lars) agree to use the UTF-8 >> version for now (and pay for the pattern/subject string/offsets >> conversions) and then write and enable a UTF-16 codepath when PCRE >> ships with proper support for it (by detecting its version at >> runtime)? >> >> Also: what's the minimum PCRE version Qt should require? I see that >> Debian 6 (stable) uses 8.02 [1], Ubuntu 10.04 LTS uses 7.8 [2]. For >> other distributions of course YMMV. Is it OK to depend on even more >> recent versions? For instance, PCRE 8.10 adds UCP support (basically >> make \w \d etc. match the corresponding Unicode properties), and PCRE >> 8.20 adds a JIT feature (which promises large perfomance benefits) [3] >> [4]. >> Again: should we resort to depend on a "old" version, detect the >> proper one at runtime, and optionally enabling those features? >> > > >I would suggest that the Qt source should include its own local copy of >pcre and a configure time switch should allow selection between the >system or the local (Qt source) version of pcre. This is already the >approach offered for things like image-related plugins (libpng, libjpg, >etc.). My main motivation for suggesting this is that, as far as I can >tell (since the Linux Foundation servers are still not back up I can't >confirm), pcre is not part of the LSB, which means if you want to build >Qt to be LSB compliant, you will need to statically link to pcre rather >than rely on the system libs. It would greatly simplify things if Qt's >own build system made this pcre library selection easy and it would also >have the benefit that if you are building Qt from source yourself rather >than relying on the system wide Qt, then you are less at the mercy of >what pcre version the system provides. This will also make it easier for >Qt to more quickly take advantage of an updated UTF-16 pcre whe > n it is implemented. On the other hand I would really like to reduce the amount of 3rdparty code that we have in qtbase.git, and not add another library there. A IMO better solution would be to have a repository called e.g. qtsupport (KDE had something similar for quite a while) that contains copies to these 3rd party libraries for convenience. Cheers, Lars _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
