ports/build-tools.nix
Build-platform code generators whose output targets Fil-C.
GLib's gdbus-codegen and glib-genmarshal, Meson's mkenums_simple, valac, gtkdoc-scangobj and the introspection scanner's gdump.c emit C for the package being built. Under Fil-C that C must treat GType as a pointer. Like a compiler, these tools are target-dependent, so patch them in the package set whose target is Fil-C (pkgsBuildHost): splicing then selects them for Fil-C nativeBuildInputs. The native package set, whose target is not Fil-C, keeps its ordinary tools.
GLib and gobject-introspection are native twins of the Fil-C ports, at the same versions: generated code must only use APIs the target GLib has, and Meson negotiates scanner options by the build GI's version. Only the target-neutral parts of the port patches apply; the rest assume Fil-C.
The twins are tools, not libraries for the build platform. Replacing pkgsBuildHost's glib would relink every native library there against GLib 2.80.4 (Pango, GTK, Qt, glibmm, SDL's PipeWire...), rebuilding them outside the binary cache and breaking those that need a newer GLib. So the twins are built from pkgsBuildHost but only the Fil-C set's view of it, pkgsBuildHost (and so buildPackages and splicing), names them; native packages inside pkgsBuildHost keep the ordinary GLib.
The ports DSL for package set pkgs, applied to one of its packages.
Native Qt programs must not propagate their native qtbase into Fil-C builds. Only the Fil-C view below uses these program-only modules and target hooks; native packages keep their ordinary Qt scope.
Select hunks of a port patch by file, keeping one source for them.
Native build tools such as gdk-pixbuf propagate the ordinary GLib, whose newer, unpatched generators can precede these on PATH and in the build pkg-config path, where Meson looks them up (gio-2.0's gdbus_codegen). Put these first once all hooks have run.
Resolve GIR includes against the Fil-C libraries being linked rather than build-platform GIRs, which XDG_DATA_DIRS lists first. The scanner searches GI_GIR_PATH before XDG_DATA_DIRS.
The Fil-C-targeted wrapper, which the set itself no longer names.
Like the GLib twins, these generators are patched only in the Fil-C-facing view, not in native libraries' own build dependencies.
Meson is not linked by native libraries, so it is patched for the whole set; meson-python there propagates it to Fil-C Python builds.
Qt's qmake hook is spliced from this set's buildPackages. Here Qt still differs from the native one without the GLib twin (qttools and so qttranslations reference another qtbase), and a native Qt module here (reached through wrapQtAppsHook, e.g. qtsvg) saw two qtbases: its setup hook failed with "detected mismatched Qt dependencies". Qt emits no GType code, so use the ordinary native Qt, which also comes from cache.nixos.org.
Likewise the gobject-introspection wrapper: with a Fil-C target it wraps the scanner for cross use and propagates the Fil-C GI, so native libraries here that link GI (PyGObject, and through it graphene, GTK 4, GStreamer, PipeWire, SDL) left the cache. Fil-C packages get the twin's wrapper from twins below.
The default targetPackages.stdenv.cc bootstraps an ordinary LLVM cross compiler for gnufilc0. Runtime wrappers are Fil-C programs too: compile them with this set's existing Fil-C compiler, not a new cross toolchain.