Hi Jakub, > -----Original Message----- > From: jakub....@gmail.com [mailto:jakub....@gmail.com] On Behalf Of Jakub > Zelenka > Sent: Tuesday, October 24, 2017 3:54 PM > To: Anatol Belski <a...@php.net> > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] PCRE2 migration > > > > On Mon, Oct 23, 2017 at 10:07 PM, Anatol Belski <a...@php.net > <mailto:a...@php.net> > wrote: > > > Hi Jakub, > > > -----Original Message----- > > From: jakub....@gmail.com <mailto:jakub....@gmail.com> > [mailto:jakub....@gmail.com <mailto:jakub....@gmail.com> ] On Behalf Of > Jakub > > Zelenka > > Sent: Monday, October 23, 2017 10:43 PM > > To: Anatol Belski <a...@php.net <mailto:a...@php.net> > > > Cc: internals@lists.php.net <mailto:internals@lists.php.net> > > Subject: Re: [PHP-DEV] [RFC] PCRE2 migration > > > > Hey > > > > > > On Mon, Oct 16, 2017 at 9:17 AM, Anatol Belski <a...@php.net > <mailto:a...@php.net> > > <mailto:a...@php.net <mailto:a...@php.net> > > wrote: > > > > > > Hi, > > > > I would like hereby to put the RFC about the PCRE2 migration for > the > > core https://wiki.php.net/rfc/pcre2-migration > <https://wiki.php.net/rfc/pcre2-migration> > > <https://wiki.php.net/rfc/pcre2-migration > <https://wiki.php.net/rfc/pcre2-migration> > under discussion. A basic > > port is available here https://github.com/php/php-src/pull/2857 > <https://github.com/php/php-src/pull/2857> > > <https://github.com/php/php-src/pull/2857 > <https://github.com/php/php-src/pull/2857> > for a > > review. > > > > > > > > > > Sorry if that's a stupid question and I'm missing something important > but why do > > we need to still bundle PCRE2? > > > I ask such questions just for the fun of it all the time, that makes > sense > to my character 😊 > > The point of the RFC is the max BC. Currently PCRE is bundled. > Otherwise, the lib is essential for the core and thus needs to be always > available. > For older distro versions like for example Debian Jessie or other OSes not yet > providing PCRE2 from the package management, that would be the only way to > get a newer PHP version, even if compiled by hand. Except maybe when libpcre2 > were provided by a third party repo, or a PPA in the Debian terminology. > > Another point on that is, even if a package is available on the target > platform - the bundled version is what is tested and highly recommended. > Builders can decide otherwise, but what we provide makes the point. Lately, > for > example - the valgrind support is also essential, as a release version > supplied by > a distro likely wouldn't be built with valgrind support but it's required to > debug > PHP issues. > > > > Otherwise, there's no need for bundling. This dependency is currently > not patched in the way it would be the only one to be required bundled. It is > simply handy to have it bundled for the development and compatibility. Any > distribution can decide, whether they would use it bundled or external. > > > > > Well I think that all listed reasons for bundling could be applied to other > libraries. > For example we won't start bundling OpenSSL just because we won't to make > the new functionality easily available. The debugging point can be also true > there because distros won't ship version configured with -d. However one can > easily compile the library in that way so I don't see it as a problem at all. > Personally I'm not a big fan of bundling libraries unless there is some > technical > reason to do so (for example an unexposed API that is necessary for inner > working of the extension). The number of PCRE2 releases and its size is of > course much smaller than for example mentioned OpenSSL but it still seems a > bit > unnecessary to me. > That's true, one could create a custom libpcre2 build with valgrind support to link externally. But, it's not about just debug build or symbols, JIT compiled patterns are a self-modifying code, valgrind enabled tests would not get it right without a special valgrind integration. Almost needed for dev and bug fixing.
> > Anyway this is something that can be discussed separately as we already bundle > PCRE so this is just a bundle replacement that actually reduces the number of > bundled lines... :) > Yeah, the RFC's approach is to have same status as it is now, but with PCRE2 instead of PCRE. More like about solving the principal question than going into further details. Regards Anatol
