sergio/takana

1# ATK 2.38.0 — la capa de accesibilidad de GTK. Primer ladrillo de la PLATAFORMA GECKO.
2#
3# ══ POR QUÉ ENTRA AHORA: ES LO ÚNICO QUE LE FALTA A GTK3 ═══════════════════════════════════════
4# Firefox —y con él Waterfox y Zen, que son forks de Gecko— sólo tiene un toolkit en Linux: GTK3.
5# GTK3 no existía en ninguna cola, y al medir su cierre resultó que **todo lo demás YA está en el
6# corpus** (glib, cairo, pango, gdk-pixbuf, libepoxy, harfbuzz, fribidi, libxml2, wayland,
7# wayland-protocols, libxkbcommon). El único hueco era éste. Un ladrillo chico destrabando una pieza
8# grande: por eso va primero.
9#
10# ══ AL CORPUS, Y NO A UNA COLA — LA REGLA QUE OBS NO PUDO CUMPLIR ══════════════════════════════
11# Las tres —Firefox, Waterfox, Zen— comparten esta plataforma entera, y una app compartida sólo se
12# alcanza desde el CORPUS: una receta resuelve sibling-first y después el catálogo padre, nunca una
13# cola hermana. Es exactamente la lección que dejó mpv, y lo contrario de lo que le pasó a OBS, que
14# quedó atado a `incoming-kde` porque Qt6 vive sólo ahí. La plataforma Gecko nace bien puesta para
15# que los tres navegadores no repitan ese error.
16#
17# ══ SÓLO GObject, SIN X11 NI GI ════════════════════════════════════════════════════════════════
18# `-Dintrospection=false`: la introspección exige gobject-introspection y sólo la usan los bindings
19# dinámicos (gjs/PyGObject). GTK3 la consume en C, y un consumidor en C no la necesita. Es también
20# lo que evita repetir la torre de [[gnome-introspection-dinamica]] sin razón.
21# `-Ddocs=false`: gtk-doc no está en el corpus y la documentación no entra al artefacto.
22name    = "atk"
23version = "2.38.0"
24license = "LGPL-2.1-or-later"
25
26[source]
27tarball = "https://download.gnome.org/sources/atk/2.38/atk-2.38.0.tar.xz"
28sha256  = "ac4de2a4ef4bd5665052952fe169657e65e895c5057dffb3c2a810f6191a0c36"
29
30[build]
31compiler = "zig-cc"
32target   = "x86_64-linux-musl"
33# DINÁMICO: GTK3 es una librería compartida y ATK entra en su cierre; un `.a` no-PIC dentro de
34# `libgtk-3.so` es el cuadro de gdk-pixbuf otra vez.
35link  = "dynamic"
36flags = []
37
38[build.phases]
39configure = "PYTHONPATH=/usr/lib/python3.12/site-packages meson setup output --prefix=/usr --buildtype=release -Ddefault_library=shared -Dintrospection=false -Ddocs=false"
40compile   = "PYTHONPATH=/usr/lib/python3.12/site-packages ninja -C output"
41install   = "PYTHONPATH=/usr/lib/python3.12/site-packages DESTDIR=/out meson install -C output --no-rebuild"
42
43[deps]
44# ══ LAS VARIANTES `-shared`, Y NO LAS ESTÁTICAS — MEDIDO EL 2026-09-05 ═════════════════════════
45# `atk` produce un OBJETO COMPARTIDO (`libatk-1.0.so`). Con la glib estática, el enlazador absorbe
46# GObject ENTERO dentro de esa `.so`, y entonces todo proceso que cargue atk y libgobject a la vez
47# tiene DOS sistemas de tipos de GObject compitiendo. No es teoría: así murió el primer atuq que se
48# intentó abrir, y el síntoma no nombra a atk por ningún lado —
49#
50#     GLib-GObject-CRITICAL: cannot register existing type 'gpointer'
51#     … 45 líneas … Segmentation fault (exit 139)
52#
53# Se encontró midiendo, no leyendo: `nm -D --defined-only` sobre cada `.so` del rootfs buscando
54# quién DEFINE `g_type_register_static`. Salieron dos: `libgobject-2.0.so` (que debe) y
55# `libatk-1.0.so` (que no).
56#
57# Es la regla que el corpus ya tenía escrita desde GTK4: las deps de una `.so` van a las variantes
58# `-shared` **en lugar de** las estáticas, jamás junto a ellas (las dos instalan los mismos `.pc` y
59# cabeceras, así que declarar ambas son dos artefactos peleando por el mismo fichero).
60build = ["meson", "samurai", "python3", "pkgconf", "glib-shared", "pcre2-shared", "libffi-shared", "zlib-shared"]