Hi,
Sorry for the late response on this one. We've been backlogged.
On Wed, 27 Jan 2016 17:37:42 +0200
Valery Kartel <valery.kartel@gmail.com> wrote:
> diff --git a/main/glib/APKBUILD b/main/glib/APKBUILD> index 930e54f..f73ffe5 100644> @@ -40,41 +38,40 @@ build() {> --mandir=/usr/share/man \> --disable-gtk-doc \> --disable-compile-warnings \> + --with-pcre=system \> + --with-pic \
--with-pic is probably not required. And the system PCRE is kind of
discouraged by glib.
https://developer.gnome.org/glib/stable/glib-building.html sayeth:
...
GRegex uses the PCRE library for regular expression matching. The
default is to use the internal version of PCRE that is patched to use
GLib for memory management and Unicode handling. If you prefer to use
the system-supplied PCRE library you can pass the --with-pcre=system
option to, but it is not recommended.
... and ...
--with-pcre. Specify whether to use the internal or the
system-supplied PCRE library.
'internal' means that GRegex will be compiled to use the internal
PCRE library.
'system' means that GRegex will be compiled to use the
system-supplied PCRE library.
Using the internal PCRE is the preferred solution:
System-supplied PCRE has a separated copy of the big tables used
for Unicode handling.
Some systems have PCRE libraries compiled without some needed
features, such as UTF-8 and Unicode support.
PCRE uses some global variables for memory management and other
features. In the rare case of a program using both GRegex and PCRE
(maybe indirectly through a library), this variables could lead to
problems when they are modified.
...
While generally we prefer to use system libraries. But I'm wondering is
it useful in this case as upstream has modified package, and they spend
lot of paragaphs explaining why it's not good idea.
I suppose if our PCRE has utf8 in good condition. The real reason would
be the pcre's global state. Do you know if this is fixed in pcre
releases, or if the above concern is valid?
All this said, the other package splitting changes and bash-completion
stuff looks good.
Perhaps you could send that separately first? I'm happy to apply it
right away. But this --with-pcre=system probably needs comments from
others and a bit more of discussion.
Thanks,
Timo
---
Unsubscribe: alpine-aports+unsubscribe@lists.alpinelinux.org
Help: alpine-aports+help@lists.alpinelinux.org
---
2016-02-23 14:05 GMT+02:00 Timo Teras <timo.teras@iki.fi>:
> Hi,>> Sorry for the late response on this one. We've been backlogged.>> On Wed, 27 Jan 2016 17:37:42 +0200> Valery Kartel <valery.kartel@gmail.com> wrote:>> > diff --git a/main/glib/APKBUILD b/main/glib/APKBUILD> > index 930e54f..f73ffe5 100644> > @@ -40,41 +38,40 @@ build() {> > --mandir=/usr/share/man \> > --disable-gtk-doc \> > --disable-compile-warnings \> > + --with-pcre=system \> > + --with-pic \>> --with-pic is probably not required. And the system PCRE is kind of> discouraged by glib.>> Yes, you are right --with-pic does not need there.
I just test to compile latest version of glib (2.47.6) And it requires
system pcre by default (minimal required version is 8.13) a bundled pcre
now stays as workaround.
What do you think to be better: bump to latest glib or just add
bash-completion to current one?
PS: as an upstream wrote 2.46 and 2.47 ABI-s 100% compatible