archlinux-s390x/scripts/devtools/arch-cmake

#!/usr/bin/env bash
# Minimal stand-in for devtools' arch-cmake, same reasoning as arch-meson.
exec cmake \
    -DCMAKE_BUILD_TYPE=None \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DCMAKE_INSTALL_LIBDIR=lib \
    -DCMAKE_INSTALL_LIBEXECDIR=lib \
    -DCMAKE_INSTALL_SBINDIR=bin \
    -DBUILD_SHARED_LIBS=ON \
    -Wno-dev \
    "$@"
[ADD] devtools stand-ins, and lib32 removal for glibc and gcc The same x86 assumption keeps returning in a different disguise: a 32-bit multilib split package. libtool had it, and so do glibc and gcc. On x86_64 multilib means i686 and Arch wants it; on Z it means the 31-bit ESA/390 ABI that GCC is actively removing: configure: error: Support for -m31 is deprecated and will be removed. glibc is the clearest case. The whole compile SUCCEEDS and the glibc package is written -- then makepkg aborts in package_lib32-glibc() with "No rule to make target install", because the 32-bit tree was never configured. The work was done; only the packaging of a tree nobody built failed. gcc needed three cuts: front ends written in themselves (Ada, D, Modula-2, COBOL have no bootstrap compiler here), multilib, and every lib32 reference including the _pick lines that split out usr/lib32. arch-meson and arch-cmake are provided as stand-ins. Several PKGBUILDs call them, they ship in devtools, and devtools is itself an Arch package -- so during a bootstrap they cannot exist yet and every PKGBUILD using them stops on "command not found". A verification lesson, learned twice: grepping a whole PKGBUILD for "lib32" declares false failures, because the string survives in comments and in functions that are never called. Only the pkgname array matters, since that is what makepkg iterates. --- FR --- La meme hypothese x86 revient sans cesse sous un autre deguisement : un paquet scinde multilib 32 bits. libtool l avait, glibc et gcc aussi. Sur x86_64 le multilib signifie i686 et Arch le veut ; sur Z il designe l ABI 31 bits ESA/390 que GCC est en train de retirer. glibc est le cas le plus net. Toute la compilation REUSSIT et le paquet glibc est ecrit -- puis makepkg abandonne dans package_lib32-glibc() sur « No rule to make target install », parce que l arbre 32 bits n a jamais ete configure. Le travail etait fait ; seul l empaquetage d un arbre que personne n avait bati a echoue. gcc demandait trois coupes : les frontaux ecrits en eux-memes (Ada, D, Modula-2 et COBOL n ont ici aucun compilateur d amorcage), le multilib, et toute reference a lib32 y compris les lignes _pick qui extraient usr/lib32. arch-meson et arch-cmake sont fournis en substituts. Plusieurs PKGBUILD les appellent, ils vivent dans devtools, et devtools est lui-meme un paquet Arch -- pendant un amorcage ils ne peuvent donc pas exister, et chaque PKGBUILD qui les utilise s arrete sur « command not found ». Une lecon de verification, apprise deux fois : chercher « lib32 » dans tout un PKGBUILD declare de faux echecs, car la chaine survit dans les commentaires et dans des fonctions jamais appelees. Seul le tableau pkgname compte, puisque c est lui que makepkg parcourt. Assisted-by: Claude Opus 5 2026-08-15 21:15:01 -04:00			`#!/usr/bin/env bash`
			`# Minimal stand-in for devtools' arch-cmake, same reasoning as arch-meson.`
			`exec cmake \`
			`-DCMAKE_BUILD_TYPE=None \`
			`-DCMAKE_INSTALL_PREFIX=/usr \`
			`-DCMAKE_INSTALL_LIBDIR=lib \`
			`-DCMAKE_INSTALL_LIBEXECDIR=lib \`
			`-DCMAKE_INSTALL_SBINDIR=bin \`
			`-DBUILD_SHARED_LIBS=ON \`
			`-Wno-dev \`
			`"$@"`