# ATK 2.38.0 — la capa de accesibilidad de GTK. Primer ladrillo de la PLATAFORMA GECKO.
#
# ══ POR QUÉ ENTRA AHORA: ES LO ÚNICO QUE LE FALTA A GTK3 ═══════════════════════════════════════
# Firefox —y con él Waterfox y Zen, que son forks de Gecko— sólo tiene un toolkit en Linux: GTK3.
# GTK3 no existía en ninguna cola, y al medir su cierre resultó que **todo lo demás YA está en el
# corpus** (glib, cairo, pango, gdk-pixbuf, libepoxy, harfbuzz, fribidi, libxml2, wayland,
# wayland-protocols, libxkbcommon). El único hueco era éste. Un ladrillo chico destrabando una pieza
# grande: por eso va primero.
#
# ══ AL CORPUS, Y NO A UNA COLA — LA REGLA QUE OBS NO PUDO CUMPLIR ══════════════════════════════
# Las tres —Firefox, Waterfox, Zen— comparten esta plataforma entera, y una app compartida sólo se
# alcanza desde el CORPUS: una receta resuelve sibling-first y después el catálogo padre, nunca una
# cola hermana. Es exactamente la lección que dejó mpv, y lo contrario de lo que le pasó a OBS, que
# quedó atado a `incoming-kde` porque Qt6 vive sólo ahí. La plataforma Gecko nace bien puesta para
# que los tres navegadores no repitan ese error.
#
# ══ SÓLO GObject, SIN X11 NI GI ════════════════════════════════════════════════════════════════
# `-Dintrospection=false`: la introspección exige gobject-introspection y sólo la usan los bindings
# dinámicos (gjs/PyGObject). GTK3 la consume en C, y un consumidor en C no la necesita. Es también
# lo que evita repetir la torre de [[gnome-introspection-dinamica]] sin razón.
# `-Ddocs=false`: gtk-doc no está en el corpus y la documentación no entra al artefacto.
name    = "atk"
version = "2.38.0"
license = "LGPL-2.1-or-later"

[source]
tarball = "https://download.gnome.org/sources/atk/2.38/atk-2.38.0.tar.xz"
sha256  = "ac4de2a4ef4bd5665052952fe169657e65e895c5057dffb3c2a810f6191a0c36"

[build]
compiler = "zig-cc"
target   = "x86_64-linux-musl"
# DINÁMICO: GTK3 es una librería compartida y ATK entra en su cierre; un `.a` no-PIC dentro de
# `libgtk-3.so` es el cuadro de gdk-pixbuf otra vez.
link  = "dynamic"
flags = []

[build.phases]
configure = "PYTHONPATH=/usr/lib/python3.12/site-packages meson setup output --prefix=/usr --buildtype=release -Ddefault_library=shared -Dintrospection=false -Ddocs=false"
compile   = "PYTHONPATH=/usr/lib/python3.12/site-packages ninja -C output"
install   = "PYTHONPATH=/usr/lib/python3.12/site-packages DESTDIR=/out meson install -C output --no-rebuild"

[deps]
# ══ LAS VARIANTES `-shared`, Y NO LAS ESTÁTICAS — MEDIDO EL 2026-09-05 ═════════════════════════
# `atk` produce un OBJETO COMPARTIDO (`libatk-1.0.so`). Con la glib estática, el enlazador absorbe
# GObject ENTERO dentro de esa `.so`, y entonces todo proceso que cargue atk y libgobject a la vez
# tiene DOS sistemas de tipos de GObject compitiendo. No es teoría: así murió el primer atuq que se
# intentó abrir, y el síntoma no nombra a atk por ningún lado —
#
#     GLib-GObject-CRITICAL: cannot register existing type 'gpointer'
#     … 45 líneas … Segmentation fault (exit 139)
#
# Se encontró midiendo, no leyendo: `nm -D --defined-only` sobre cada `.so` del rootfs buscando
# quién DEFINE `g_type_register_static`. Salieron dos: `libgobject-2.0.so` (que debe) y
# `libatk-1.0.so` (que no).
#
# Es la regla que el corpus ya tenía escrita desde GTK4: las deps de una `.so` van a las variantes
# `-shared` **en lugar de** las estáticas, jamás junto a ellas (las dos instalan los mismos `.pc` y
# cabeceras, así que declarar ambas son dos artefactos peleando por el mismo fichero).
build = ["meson", "samurai", "python3", "pkgconf", "glib-shared", "pcre2-shared", "libffi-shared", "zlib-shared"]