archlinux-s390x/patches/pkgbuild/cmake.sh

136 lines
6.1 KiB
Bash
Raw Normal View History

[ADD] the build systems stage 2 rebuilds with Ten of the 159 PKGBUILDs call arch-meson and four call cmake, so a chroot without them could rebuild most of the repository and then stop. Neither is a dependency of anything in the repository, which is why no closure round ever named them -- the same shape as fakeroot and bison, one layer up. python returns with meson, and that is not the earlier decision being reversed. Dropping python at stage 1 was about what the REPOSITORY must supply: it was wanted only by two wheels Arch's own python could not load. This is about what the BUILD ENVIRONMENT must contain, and meson is written in Python. Different question, different answer. python needed two fixes of its own. Its xvfb loop is in build() AND in check(); stage 1 never ran the second because of --nocheck, but stage 2 drops --nocheck on purpose, so it would have spun there too. And Python 3.13 removed the vendored libmpdec, so --with-system-libmpdec is the only way to build and needs the host headers -- reported nine hundred lines in as a missing make rule for a file that used to be vendored. cmake wanted rhash, then jsoncpp, then cppdap, one at a time. That is a queue, and the rule in install_host_deps says a queue is a feature to disable. Not applied here, deliberately: each exists as an Ubuntu package, so the queue ends. The rule is for queues that do not, like dbus reaching a documentation tool that needed Qt. Its Qt GUI is dropped -- a dialog box on a headless mainframe. --- FR --- Dix des 159 PKGBUILD appellent arch-meson et quatre appellent cmake : un chroot sans eux pourrait reconstruire l'essentiel du dépôt puis s'arrêter. Aucun des deux n'est une dépendance de quoi que ce soit dans le dépôt, ce qui explique qu'aucun tour de fermeture ne les ait nommés — même forme que fakeroot et bison, une couche plus haut. python revient avec meson, et ce n'est pas un revirement. L'écarter à l'étage 1 portait sur ce que le DÉPÔT doit fournir : il n'était voulu que par deux roues que le python d'Arch ne pouvait pas charger. Ici il s'agit de ce que l'ENVIRONNEMENT DE BUILD doit contenir, et meson est écrit en Python. Autre question, autre réponse. python a demandé deux correctifs propres. Sa boucle xvfb est dans build() ET dans check() ; l'étage 1 n'a jamais exécuté la seconde grâce à --nocheck, mais l'étage 2 l'abandonne exprès — elle y aurait tourné aussi. Et Python 3.13 a retiré le libmpdec embarqué : --with-system-libmpdec est la seule voie et réclame les en-têtes de l'hôte, signalé neuf cents lignes plus loin comme une règle make manquante pour un fichier autrefois embarqué. cmake a réclamé rhash, puis jsoncpp, puis cppdap, un par un. C'est une file, et la règle d'install_host_deps dit qu'une file est une fonctionnalité à désactiver. Non appliquée ici, délibérément : chacun existe en paquet Ubuntu, donc la file se termine. La règle vise celles qui ne terminent pas, comme dbus atteignant un outil de documentation qui exigeait Qt. Son interface Qt est retirée — une boîte de dialogue sur un mainframe sans écran. Assisted-by: Claude Opus 5
2026-08-19 19:53:46 -04:00
#!/usr/bin/env bash
# cmake: --qt-gui, on a machine with no display and no Qt.
#
# CMake Error at Source/QtDialog/CMakeLists.txt:33 (message):
# Error when bootstrapping CMake:
#
# cmake-gui is a Qt application. Arch lists qt6-base in makedepends and builds
# it; this port has no Qt and will not grow one to give a bootstrap a dialog
# box. Same reasoning as pinentry's Qt front end, and the cost is the same
# thing: a graphical program nothing here can display.
#
# WHY cmake IS IN STAGE 1 AT ALL, since it is worth being clear that this is
# not scope creep: four PKGBUILDs call cmake directly, and stage 2 rebuilds
# every package inside a chroot that has to contain the build systems. cmake
# is a tool the REBUILD needs, not a dependency of anything in the repository
# -- which is why the dependency resolver never asked for it.
#
# --sphinx-man and --sphinx-html stay: sphinx-build is installed, and the man
# pages are worth having.
#
# The makedepends entry goes with the flag. Nothing checks it under --nodeps,
# but a package declaring a build dependency it does not use is the same
# untruth as gcc-libs declaring libhwasan -- and leaving it would tell the
# next reader that Qt was needed here.
set -euo pipefail
python3 - <<'ZZPY'
import io
s = io.open("PKGBUILD", encoding="utf-8").read()
old = " --qt-gui \\\n"
assert s.count(old) == 1, "cmake: expected exactly one --qt-gui"
s = s.replace(old, "", 1)
old = " qt6-base)"
assert s.count(old) == 1, "cmake: makedepends tail not in the expected form"
s = s.replace(old, " )", 1)
io.open("PKGBUILD", "w", encoding="utf-8").write(s)
ZZPY
grep -q -- '--qt-gui' PKGBUILD && { echo "cmake: --qt-gui survived" >&2; exit 1; }
sed -n '/^makedepends=(/,/)/p' PKGBUILD | grep -q 'qt6-base' && {
echo "cmake: qt6-base still in makedepends" >&2; exit 1; }
grep -q -- '--sphinx-man' PKGBUILD || {
echo "cmake: man pages lost with the GUI" >&2; exit 1; }
echo "cmake: --qt-gui dropped (no Qt, no display)"
[FIX] stage 2: x86_64 compiler flags, and a .pc naming nothing Two failures three packages apart, both from the same place: our pacman package ships Arch's configuration verbatim, and Arch's is for x86_64. libxml2/meson.build:1:0: ERROR: Unable to detect linker for compiler `cc ... -march=x86-64 -mtune=generic ...` configure_chroot fixed CARCH, CHOST, MAKEFLAGS and OPTIONS and left CFLAGS alone. They are emptied rather than translated, because that is what stage 1 used -- the host's makepkg.conf has no CFLAGS line at all -- and 179 working packages are the evidence. s390x tuning is a deliberate later choice. Emptied by APPENDING, not commenting. The first attempt put a # in front of each assignment, and CFLAGS spans several lines: commenting the first left the continuations active and the quote unbalanced, so makepkg would not start. Then readline. Its .pc says `Requires.private: termcap` and this repository ships tinfo.pc; nothing provides termcap.pc. Nothing failed at build time -- a .pc is data, and pkg-config only follows Requires.private when a consumer asks. The first consumer to ask was libxml2, in the chroot, one stage and three packages from the cause. --- FR --- Deux échecs à trois paquets d'écart, de la même origine : notre paquet pacman livre la configuration d'Arch telle quelle, et celle d'Arch vise x86_64. libxml2/meson.build:1:0: ERROR: Unable to detect linker for compiler `cc ... -march=x86-64 -mtune=generic ...` configure_chroot corrigeait CARCH, CHOST, MAKEFLAGS et OPTIONS, et laissait CFLAGS. Ils sont vidés plutôt que traduits, car c'est ce qu'a utilisé l'étage 1 — le makepkg.conf de l'hôte n'a aucune ligne CFLAGS — et 179 paquets fonctionnels en sont la preuve. Le réglage pour s390x est un choix ultérieur délibéré. Vidés par AJOUT, non par commentaire. La première tentative mettait un # devant chaque affectation, et CFLAGS s'étend sur plusieurs lignes : commenter la première laissait les continuations actives et le guillemet déséquilibré, si bien que makepkg ne démarrait plus. Puis readline. Son .pc dit « Requires.private: termcap » alors que ce dépôt livre tinfo.pc ; personne ne fournit termcap.pc. Rien n'échouait à la compilation — un .pc est une donnée, et pkg-config ne suit Requires.private que si un consommateur le demande. Le premier à demander fut libxml2, dans le chroot, à une étape et trois paquets de la cause. Assisted-by: Claude Opus 5
2026-08-19 20:19:37 -04:00
# emacs, for one lisp file, at the very last line of package().
#
# PKGBUILD: line 64: emacs: command not found
#
# The build compiled everything, generated the sphinx documentation, installed
# the whole tree, and then died on
#
# emacs -batch -f batch-byte-compile .../site-lisp/cmake-mode.el
#
# make install already put cmake-mode.el in place; this only produces the
# byte-compiled .elc beside it. Emacs loads the .el perfectly well without it,
# a little slower on first load. Installing emacs -- forty megabytes and its
# own dependency tree -- to pre-compile one editor mode for a bootstrap that
# has no editor is not a trade worth making.
#
# THE SHAPE IS WORTH NOTING because it is the third time: pam's PDF removal,
# e2fsprogs' fuse2fs removal, and now this. A failure on the LAST line of
# package(), after a completely successful build, always looks like something
# broke badly. It never is -- it is a tool the host does not have, doing
# something optional.
set -euo pipefail
python3 - <<'ZZPY'
import io
s = io.open("PKGBUILD", encoding="utf-8").read()
old = ' emacs -batch -f batch-byte-compile "${pkgdir}"/usr/share/emacs/site-lisp/cmake-mode.el\n'
assert s.count(old) == 1, "cmake: the emacs byte-compile line is not in the expected form"
s = s.replace(old, "", 1)
old = "makedepends=(emacs\n"
assert s.count(old) == 1, "cmake: makedepends does not start with emacs"
s = s.replace(old, "makedepends=(\n", 1)
io.open("PKGBUILD", "w", encoding="utf-8").write(s)
ZZPY
grep -q 'emacs -batch' PKGBUILD && { echo "cmake: the emacs step survived" >&2; exit 1; }
sed -n '/^makedepends=(/,/)/p' PKGBUILD | grep -qw emacs && {
echo "cmake: emacs still in makedepends" >&2; exit 1; }
grep -q 'cmake-mode' PKGBUILD && {
echo "cmake: a cmake-mode reference remains -- check it is harmless" >&2; }
echo "cmake: emacs byte-compilation dropped (the .el is installed regardless)"
# --- no Sphinx documentation ---------------------------------------------------
#
# CMake Error at Utilities/Sphinx/CMakeLists.txt:52 (message):
#
# cmake builds its own manual and man pages with Sphinx, requested by
# --sphinx-man and --sphinx-html in the bootstrap arguments. python-sphinx is not
# in this port: it is a large Python documentation stack, and cmake is wanted here
# as a build tool.
#
# BOTH FLAGS, and they are bootstrap arguments rather than -D options -- cmake
# configures itself with its own script before it can run itself. Dropping only
# one leaves the other pulling Sphinx in, and the error is identical, which is how
# a half-fix looks like no fix.
set -euo pipefail
python3 - <<'ZZPY'
import io, re
lines = io.open("PKGBUILD", encoding="utf-8").read().split("\n")
hit = [i for i, l in enumerate(lines) if re.match(r"^[ \t]*--sphinx-(man|html)[ \t]*\\\\?$", l)]
assert len(hit) == 2, "cmake: expected two --sphinx flags, got %d" % len(hit)
# Backwards: deleting shifts everything after it.
for i in reversed(hit):
del lines[i]
io.open("PKGBUILD", "w", encoding="utf-8").write("\n".join(lines))
ZZPY
grep -qE "^[[:space:]]*--sphinx-" PKGBUILD && {
echo "cmake: a --sphinx flag survived" >&2; exit 1; }
echo "cmake: Sphinx manual and man pages dropped"
[FIX] binutils records a usr/lib64 path, and cmake deletes html it did not make pacman refused the rebuilt binutils: binutils: <root>/usr/lib64 exists in filesystem (owned by filesystem) binutils: <root>/usr/lib64/libiberty.a exists in filesystem --libdir=/usr/lib was not enough. libiberty installs into $(libdir)$(MULTIOSSUBDIR), and gcc reports ../lib64 for -print-multi-os-directory on s390x. In the installed system that resolves through the symlink filesystem now provides, so the file lands in /usr/lib -- but pkgdir has no symlink, so make creates a real pkg/usr/lib64/ and makepkg records the literal path. The two fixes are not alternatives: the symlink is what keeps meson and cmake choosing lib, and this moves the one file that still writes through the multi-os subdirectory. cmake is the eleventh instance of removing a documentation build and leaving its cleanup: with Sphinx off there is no html, and the PKGBUILD deletes _sources from it. rm -rf rather than deleted -- on a machine with Sphinx it is real. The binutils hook also assumed package_binutils(). binutils is not a split package; its own assertion caught that. --- FR --- pacman a refusé le binutils reconstruit : binutils: <root>/usr/lib64 exists in filesystem (owned by filesystem) binutils: <root>/usr/lib64/libiberty.a exists in filesystem --libdir=/usr/lib ne suffisait pas. libiberty s'installe dans $(libdir)$(MULTIOSSUBDIR), et gcc annonce ../lib64 pour -print-multi-os-directory sur s390x. Dans le système installé cela se résout par le lien que filesystem fournit désormais, donc le fichier atterrit dans /usr/lib — mais pkgdir n'a pas de lien : make crée un vrai pkg/usr/lib64/ et makepkg enregistre le chemin littéral. Les deux correctifs ne sont pas des alternatives : le lien est ce qui fait choisir lib à meson et cmake, et celui-ci déplace le seul fichier qui écrive encore par le sous-répertoire multi-os. cmake est la onzième occurrence du retrait d'une documentation sans son nettoyage : sans Sphinx il n'y a pas de html, et le PKGBUILD en supprime _sources. rm -rf plutôt que supprimé — sur une machine dotée de Sphinx, il est réel. Le hook binutils supposait aussi package_binutils(). binutils n'est pas un paquet scindé ; sa propre assertion l'a arrêté. Assisted-by: Claude Opus 5
2026-08-23 22:05:26 -04:00
# --- and the html it no longer generates --------------------------------------
#
# rm: cannot remove '<pkgdir>/usr/share/doc/cmake/html/_sources': No such file
#
# ELEVENTH time in this port. With Sphinx off, cmake generates no html, and the
# PKGBUILD deletes _sources from it -- Sphinx leaves the reStructuredText inputs
# beside the rendered pages and they are not wanted in a package.
#
# rm -rf rather than deleted: on a machine with Sphinx the directory is real and
# still has to go.
python3 - <<'ZZPY'
import io, re
lines = io.open("PKGBUILD", encoding="utf-8").read().split("\n")
hit = [i for i, l in enumerate(lines) if "_sources" in l and l.lstrip().startswith("rm ")]
assert len(hit) == 1, "cmake: expected one _sources removal, got %d" % len(hit)
i = hit[0]
lines[i] = lines[i].replace("rm -r ", "rm -rf ", 1)
io.open("PKGBUILD", "w", encoding="utf-8").write("\n".join(lines))
ZZPY
grep -qE "^[[:space:]]*rm -rf .*_sources" PKGBUILD || {
echo "cmake: the _sources removal was not made tolerant" >&2; exit 1; }
echo "cmake: _sources cleanup tolerates its absence"