Building only GTK4 unstable

[DominusExult]

I've tried building only GTK4 with moduleset="https://gitlab.gnome.org/GNOME/gtk-osx/raw/master/modulesets-unstable/gtk-osx.modules" and these commands:

jhbuild bootstrap-gtk-osx
jhbuild build meta-gtk-osx-bootstrap
jhbuild build gtk-4 

But this seems to be insufficient. The most glaring problem was that it didn't build the gdk-pixbuf loaders (except gif and tiff which it build). This causes of course to not display some theme elements and our program also makes use of xpm which also can't work without these.

Additionally, quick comparison shows these libs to be "missing" (some might not be needed, though)

libcroco-0.6.dylib
libgailutil-3.0.dylib
libgdk-3.0.dylib
librsvg-2.2.dylib
libxml2.2.dylib

Before bringing this up as an issue, I thought better to ask here in case I made an user error :)

[jralls]

The only loaders that gdk-pixbuf builds by default are png, jpeg, gif, and tiff, the first two of which are built-in. There's an optional "others" option that you can pass in your jhbuildrc-custom (module_mesonargs['gdk-pixbuf'] = "-Dothers=enabled") to 'Enable other loaders, which are weakly maintained' as meson_options.txt says. If you only need a few you could add them as builtins with -Dbuiltin_loaders=["jpeg", "png", "xpm"] instead, see meson_options.txt for the list.
librsvg provides the svg loader.
libgdk-3.0 is obviously for Gtk3. librsvg is used by adwaita-icon-theme, which you may or may not need and librsvg is the only thing that depends on libxml2 any more. gettext builds its own libcroco now so we don't need it as a separate module. libgail was a Gtk2 accessibility library whose last release was in February 2011.

[DominusExult]

:)
Another problem in configure phase of librsvg:

*** Configuring librsvg *** [24/25]
meson --prefix /opt/gtk4 --libdir lib -Dintrospection=disabled -Ddocs=disabled --wrap-mode=nofallback /Users/Dominus/gtk/source/librsvg
The Meson build system
Version: 1.4.1
Source dir: /Users/Dominus/gtk/source/librsvg
Build dir: /Users/Dominus/.cache/jhbuild/build/librsvg
Build type: native build
Project name: librsvg
Project version: 2.58.91
C compiler for the host machine: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang (clang 15.0.0 "Apple clang version 15.0.0 (clang-1500.3.9.4)")
C linker for the host machine: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang ld64 1053.12
Host machine cpu family: aarch64
Host machine cpu: aarch64
Program cargo found: YES 1.79.0 1.79.0 (/Users/Dominus/.new_local/bin/cargo)
Program meson/cargo_wrapper.py found: YES (/Users/Dominus/gtk/source/librsvg/meson/cargo_wrapper.py)
Program cargo-cbuild found: NO

../../../../gtk/source/librsvg/meson.build:29:10: ERROR: Program 'cargo-cbuild' not found or not executable

A full log can be found at /Users/Dominus/.cache/jhbuild/build/librsvg/meson-logs/meson-log.txt
WARNING: Running the setup command as `meson [options]` instead of `meson setup [options]` is ambiguous and deprecated.
*** Error during phase configure of librsvg: ########## Error running meson --prefix /opt/gtk4 --libdir lib -Dintrospection=disabled -Ddocs=disabled --wrap-mode=nofallback /Users/Dominus/gtk/source/librsvg *** [24/25]

[jralls]

Oh, right, I forgot about that one. I haven't figured out how to automate it. From a jhbuild shell run

cargo install cargo-c --features=vendored-openssl

then quit the shell and re-run configuration.

[DominusExult]

Thank you, getting there :)

Your libxml2 fix was incorrect, though. it should be repo="ftp.gnome.org" AFAICT (jusdging from other repo= cases and this worked right now for me)

[DominusExult]

So, updating gdk-pixbuf a success, and installing adwaita-icon-theme a success as well.

But the svg lib has another little problem: it adds libpixbufloader_svg.dylib to gdk-pixbuf loaders instead of an .so file (which will later confuse gtk-mac-bundler as it will only copy .so files by default).
AND AFAICT it doesn't update the gdk-pixbuf loaders cache with the svg stuff (which can be done manually and is mentioned in the build logs, if you know what to look for).

[jralls]

Your libxml2 fix was incorrect, though.

Well, half-wrong (modulesets was right), and not the way you thought: It's download.gnome.org in every other moduleset so I changed that one to match. Thanks for telling me.

[DominusExult]

Desperately :) trying to rebuild GTK-4 unstable I've run into a problem with glib-no-introspection:

../../../../gtk/source/glib/meson.build:960:2: ERROR: Value "gnu99,c99" (of type "string") for combo option "C language standard to use" is not one of the choices. Possible choices are (as string): "none", "c89", "c99", "c11", "c17", "gnu89", "gnu99", "gnu11", "gnu17".

As above my only changes to jhbuildrc-custom are:

module_mesonargs['gdk-pixbuf'] = "-Dothers=enabled"
prefix = '/opt/gtk4'
setup_sdk(target="14.5")
moduleset="https://gitlab.gnome.org/GNOME/gtk-osx/raw/master/modulesets-unstable/gtk-osx.modules"

Any idea what is happening here? (my guess is that master of glib has an issue)

[DominusExult]

running meson -v in jhbuild shell returns 1.4.1 but maybe there are some dependencies that were not updated and required for this.

Edit: the only step I skipped was running "gtk-osx-setup.sh" as I already had jhbuild setup before, so maybe there is something too old, even though meson was up to date.

[jralls]

for some reason the symlink bin/pkgconf -> bin/pkg-config wasn't working

Probably because it's supposed to go the other way. It should be created correctly by pkgconf with https://gitlab.gnome.org/GNOME/gtk-osx/-/blob/master/patches/pkgconf-link-pkg-config.patch?ref_type=heads applied.

What do which meson and which python3 run in jhbuild shell return?

[DominusExult]

for some reason the symlink bin/pkgconf -> bin/pkg-config wasn't working

Probably because it's supposed to go the other way. It should be created correctly by pkgconf with https://gitlab.gnome.org/GNOME/gtk-osx/-/blob/master/patches/pkgconf-link-pkg-config.patch?ref_type=heads applied.

I might have written it the wrong way around. pkgconf is the binary and pkg-config should be the symlink, right?. This wasn't working for some reason.

What do which meson and which python3 run in jhbuild shell return?

/Users/Dominus/.new_local/share/virtualenvs/etc-Mw2UFQW9/bin/meson

/Users/Dominus/.new_local/share/virtualenvs/etc-Mw2UFQW9/bin/python3
(version 3.11.7, btw)

[jralls]

The patch uses meson to create the symlink and it comes out perhaps a bit goofy:

pkg-config@ -> /Users/john/Development/gtk-unstable-11-arm64/build/pkgconf-2.2.0/pkgconf

So if you were to clean up your build directory it would fail.

[DominusExult]

Ah, yes, that explains it (especially as I found the same problem in my GTK3 prefix). It wasn't a problem after I build the prefixes since I use two prefixes together, the GTK3 one and another for non-GTK-ON-OSX libs and I pointed to that pkg-config.