GitLab

librsvg uses them to generate its documentation.

Required to build with Xcode 13.3

This reverts commit 18cd0e12 because
PYENV_VERSION is defined by pyenv and using something else breaks pyenv.

Pyenv's pip shim is for python2's pip, don't want that.

So that it will use the /Users/john/Development/Gramps-Build/gramps-51-tarball-10.12-x86_64/inst/bin:/Users/john/.local/share/virtualenvs/etc-vauAPygS/bin:/Users/john/.local/share/pyenv/shims:/Users/john/.local/bin:/usr/local/bin:/bin:/usr/bin:/sbin:/usr/sbin at runtime instead of at config time.

Because it's the python version pyenv installs, not the version of pyenv.

Also clean up some module warnings.

Fixes #45

This is in two parts. The patch is for
libxml2#317. The rest is
because while Apple provides python3 as part of Xcode 12 and 13 for
macOS 11 and 12 respectively it doesn't provide a linkable libpython3.dylib so
we can't build the python bindings for libxml2 or gobject-introspection
with it. To resolve that we force install a pyenv python3 and set up
jhbuild accordingly, and add an LDFLAGS entry to locate its library.

The 1.10.2 release is the first one which contains a universal binary (x86_64 and arm64)
and is executed as an arm64 process on ARM macs. With the previous binary, ninja did
run as a x86_64 process on ARM macs and as a result all tasks executed by ninja did run
as x86_64 processes too. This lead to the following error when compiling the
shared-mime-info package in an arm64 build (which is fixed after applying this patch):

[8/8] Generating freedesktop.org.xml with a custom command
FAILED: data/freedesktop.org.xml
/Users/jhbuild/gtk/source/shared-mime-info-2.1/data/freedesktop_generate.sh /Users/jhbuild/gtk/source/shared-mime-info-2.1 /Users/jhbuild/.cache/jhbuild/build/shared-mime-info-2.1
ninja: Entering directory `/Users/jhbuild/.cache/jhbuild/build/shared-mime-info-2.1'
[0/1] Running external command shared-mime-info-gmo (wrapped by meson to set env)
Traceback (most recent call last):
  File "/Users/jhbuild/gtk/inst/bin/itstool", line 27, in <module>
    import libxml2
  File "/Users/jhbuild/gtk/inst/lib/python3.8/site-packages/libxml2.py", line 1, in <module>
    import libxml2mod
ImportError: dlopen(/Users/jhbuild/gtk/inst/lib/python3.8/site-packages/libxml2mod.so, 0x0002): tried: '/Users/jhbuild/gtk/inst/lib/python3.8/site-packages/libxml2mod.so' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64')), '/usr/local/lib/libxml2mod.so' (no such file), '/usr/lib/libxml2mod.so' (no such file)

Use $PYTHON if it's set, otherwise prefer python3 to python as Apple
is (as of macOS 12) still setting python to python2.

Set PIP="$PYTHON -m pip" instead of a path that might point to a shell
script that requires a particular $PYTHONPATH.

If rustup is found, see if it's in DEVPREFIX; if so figure out where
so that defaults for CARGO_HOME and RUSTUP_HOME will have a better
chance of being correct. If it's not default them to the normal rust
installation defaults. If they're different they should already be set up.

Neither does anything.
Fixes #40

Fixes #40

It doesn't work consistently so somethimes jhbuild can't find the
installed meson or pygments modules.

gtk-doc no longer needs six, but does need pygments.
Fonconfig requires meson >= 0.56.0

For wider applicability. Note that it must still be set explicitly
for pipenv install to operate on the right virtenv.

Restores automatically building the needed python3 for the virtenv.

Fixes #36

And clean up, removing modules that aren't required here.

Required for building recent versions of librsvg.

Updates to jhbuildrc-gtk-osx for py3.

As a temporary workaround to master being converted to python3.

52.0 adds a dependency on the lzma module and since MacOS doesn't
provide liblzma the virtenv python doesn't build it. xz provides
liblzma and the jbhuild built Pyton3 has lzma, but that doesn't do
us any good for running meson.

Fixes #17

Fixes #16

If a package (in particular typing and enum34) is found in the system
python directories pip will notice and not install it. If we later
tell pip to uninstall it it will try and of course fail to remove it
from the system directory. Check first that the package is installed in
our directory before trying to uninstall it.

Closes #10

Blady authored May 11, 2019 and John Ralls committed May 14, 2019

Fix in case of existing $HOME/.config/jhbuildrc and $HOME/.jhbuildrc-custom, see included Numbers table.