luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2025-07-21 17:37:53 +02:00
Code Issues Packages Projects Releases Wiki Activity

build: Drop the internal_pcre option in favour of the subproject

Browse Source 
This should maintain equivalent functionality, apart from that now you
have to pass `--force-fallback-for libpcre` to `meson configure` in
order to use the subproject; rather than specifying
`-Dinternal_pcre=true` to use the internal copy.

This also fixes #642, as the wrapdb copy of libpcre is version 8.37.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Helps: #962
Fixes: #642
This commit is contained in:
Philip Withnall
2021-06-09 12:26:30 +01:00
parent 1d952150e6
commit 9fbd7f3dc1
7 changed files with 34 additions and 103 deletions
Download Patch File Download Diff File Expand all files Collapse all files

48
docs/reference/glib/building.xml
View File

@@ -153,12 +153,9 @@
<listitem>
<para>
GRegex uses the <ulink url="http://www.pcre.org/">PCRE library</ulink>
for regular expression matching. The default is to use the system
version of PCRE, to reduce the chances of security fixes going out
of sync. GLib additionally provides an internal copy of PCRE in case
the system version is too old, or does not support UTF-8; the internal
copy is patched to use GLib for memory management and to share the
same Unicode tables.
for regular expression matching. The system version of PCRE is used,
unless not available (which is the case on Android), in which case a
fallback subproject is used.
</para>
</listitem>
<listitem>
@@ -235,45 +232,6 @@
</para>
</formalpara>
<formalpara>
<title><option>-Dinternal_pcre=true</option></title>
<para>
Normally, GLib will be configured to use the system-supplied PCRE
library if it is suitable, falling back to an internal version
otherwise. If this option is specified, the internal version will always
be used.
</para>
<para>
Using the internal PCRE is the preferred solution if:
<itemizedlist>
<listitem>
<para>
your system has strict resource constraints; the system-supplied
PCRE has a separated copy of the tables used for Unicode
handling, whereas the internal copy shares the Unicode tables
used by GLib.
</para>
</listitem>
<listitem>
<para>
your system has PCRE built without some needed features,
such as UTF-8 and Unicode support.
</para>
</listitem>
<listitem>
<para>
you are planning to use both GRegex and PCRE API at the same
time, either directly or indirectly through a dependency; PCRE
uses some global variables for memory management and
other features, and if both GLib and PCRE try to access them
at the same time, this could lead to undefined behavior.
</para>
</listitem>
</itemizedlist>
</para>
</formalpara>
<formalpara>
<title><option>-Dbsymbolic_functions=false</option> and
<option>-Dbsymbolic_functions=true</option></title>