Point O : GAOL en sous-projet meson, Release par défaut, textes de C++17 et du Python du Store

[Jordan08]

Point O de TODO.md : meson et les fichiers de build (anciens 41, 42, 52 et 65). S'y ajoutent des décisions du 6 octobre, prises pendant le travail :

• GAOL se compile par défaut en Release dans les trois builds, comme projet de tête ou comme partie d'un autre projet ;
• deux phrases fausses du manuel sur -lm sont corrigées ici ;
• après la première CI verte : pipefail dans les workflows, une option de debug (enable-debug, GAOL_DEBUG) et Release en tête des configurations (dernière section).

41. GAOL en sous-projet meson

Problème. Un projet meson qui prend GAOL en sous-projet (subprojects/gaol, puis dependency('gaol', fallback: ['gaol', 'gaol_dep']) ou subproject('gaol')) s'arrête dès meson setup, avec meson 0.53.2 comme avec 1.11.2 :

subprojects/gaol/meson.build:209:4: ERROR: Function 'add_global_arguments' cannot be used in subprojects because there is no way to make that reliable.

Le commentaire de gaol_dep (gaol/meson.build) promet pourtant cet usage.

Cause. meson.build donne tous ses drapeaux par add_global_arguments(), que meson refuse dans un sous-projet : ceux de l'arithmétique d'intervalles, /fp:strict, -msse2 -mfpmath=sse, -mfma, la visibilité, -Wconversion et les optimisations de release.

Correction, comme décidé le 3 octobre :

• meson.build : add_project_arguments() à la place des 17 add_global_arguments(), avec un commentaire qui dit pourquoi ;
• gaol/meson.build : gaol_dep porte compile_args: pc_cflags, c'est-à-dire les drapeaux que gaol.pc donne au code qui utilise GAOL : -frounding-math -ffp-contract=off -fno-fast-math, et selon la machine -msse2 -msse3, -mfma, -msse2 -mfpmath=sse, -ffloat-store ou /fp:strict. Les arguments du projet GAOL n'atteignent pas les cibles du projet parent. gaol_dep avait déjà link_args: gaol_link_args (-mno-daz-ftz) ;
• meson.build, trouvé par la relecture : un GAOL sous-projet ne déclare plus ses configurations de test (add_test_setup('unit', ..., is_default: true), check) ni sa cible check. Sinon, avec meson 0.57 et suivants, un parent qui a sa propre configuration par défaut s'arrête (« 'parent:mine' is already set as default. is_default can be set to true only once »). Un parent sans configuration propre perd, lui, ses propres tests de la suite examples (meson test --list ne les montre plus).

Le build meson de GAOL lui-même ne change pas. J'ai comparé compile_commands.json avant et après, aux mêmes chemins, avec meson 0.53.2 et 1.11.2 (96 commandes, with-tests et with-examples). La bibliothèque, CORE-MATH et les tests ont les mêmes commandes. Seuls les 16 exemples, qui passent par gaol_dep, reçoivent en double les drapeaux de l'arithmétique d'intervalles (-frounding-math -ffp-contract=off -fno-fast-math -msse2 -msse3 -mfma), sans effet. L'audit des trois builds (.github/audit) ne regarde que gaol_interval.cpp.

Test. tests/meson_subproject est un projet meson qui prend GAOL en sous-projet, comme tests/fetch_content le fait avec FetchContent :

• il construit avec gaol_dep les mêmes six tests (arithmetic, elementary, rounding_direction, numbers, other_functions, reverse) ;
• il déclare sa propre configuration de test par défaut, comme le parent du problème ci-dessus ;
• son test flags (check_flags.py) vérifie que chaque commande qui compile une source du projet, hors de subprojects/, contient les Cflags du gaol.pc que le sous-projet écrit dans meson-private/ (sans le -I) ;
• son test release est décrit plus bas.

Les six tests ne suffisent pas : sans compile_args dans gaol_dep, ils passent tous (GCC 9.4, x86_64). D'où le contrôle direct des commandes.

Le sous-projet est un lien subprojects/gaol vers les sources :

• Le nouveau job meson-subproject de build-systems.yml (Ubuntu 24.04 x86_64) le crée, puis lance ninja test et le contrôle de la locale à virgule. Il tourne avec deux meson : celui de pipx, et le 1.3.2 d'Ubuntu par apt. La variante apt vérifie que son meson est antérieur à 1.8.4, sans quoi son test release ne prouverait rien.
• Sa configuration passe par set -o pipefail. La relecture a montré que, sans cela, un meson setup qui échoue ne faisait échouer que l'étape suivante.
• Le lien est ignoré par git (.gitignore) et par l'archive de CPack (CPACK_SOURCE_IGNORE_FILES, qui recopie à la main les motifs de .gitignore). Sans cette dernière ligne, un package_source fait avec le lien dans l'arbre range le lien lui-même dans gaol-5.0.0.tar.gz, vers le chemin absolu de l'arbre de celui qui fait l'archive (vérifié).
• La copie de .github/scripts/version-file.sh (tar -h) l'exclut aussi : elle suivait le lien sans fin (vérifié : au bout de 10 s, elle tournait encore). L'en-tête de tests/meson_subproject/meson.build dit de retirer le lien après usage.

Vérifié : avec les sources de configure-clean, ce test échoue.

• Avec le meson.build de configure-clean et tests/meson_subproject ajouté, meson setup s'arrête sur l'erreur add_global_arguments ci-dessus (meson 0.53.2).
• Avec la branche, mais sans la ligne compile_args: pc_cflags de gaol_dep : les six tests passent, et flags échoue :

  ../src-a/tests/arithmetic.cpp is compiled without -frounding-math -ffp-contract=off -fno-fast-math -msse2 -msse3 -mfma
  

  de même pour les cinq autres sources.
• Avec la branche, mais sans la garde meson.is_subproject() des configurations de test : meson setup s'arrête avec meson 1.7.2 et 1.11.2 (« 'gaol_tests_meson_subproject:meson_subproject' is already set as default »).
• Avec la branche : 8 sur 8 avec meson 0.53.2, 1.7.2, 1.8.0, 1.8.4 et 1.11.2.

Commande : mkdir tests/meson_subproject/subprojects && ln -s "$PWD" tests/meson_subproject/subprojects/gaol && meson setup b tests/meson_subproject && ninja -C b test.

Documentation.

• doc/using.md (fin de « From pkg-config ») et le manuel (même endroit, \newinvfive) : la recette dependency('gaol', fallback: ['gaol', 'gaol_dep']), vérifiée avec meson 0.53.2 et 1.11.2, et ce que porte gaol_dep. La relecture a vérifié que, si un gaol.pc est sur PKG_CONFIG_PATH, dependency() prend celui-là.
• doc/tests.md, doc/continuous-integration.md et README.md : tests/meson_subproject et son job.

GAOL en Release par défaut, en projet de tête ou en sous-projet

Décidé le 6 octobre : « Par défaut GAOL doit compiler en mode Release, avec les 3 builds (meson, CMake et Autotools) en projet ou sous-projets. » J'ai mesuré chaque build quand le projet parent ne choisit pas de type de build.

meson. Le buildtype=release des default_options de GAOL ne vaut pas pour un sous-projet avant meson 1.8.4. Flags de gaol_interval.cpp, parent laissé au debug par défaut :

meson	GAOL en sous-projet, avant la correction
0.53.2, 0.54.3, 0.57.2, 0.60.3	le type de build et la norme C++ du parent : -g, sans -O3 ni NDEBUG, et GAOL_DEBUGGING défini
0.63.3, 0.64.1, 1.0.2, 1.3.2, 1.5.2, 1.6.1, 1.7.2	-std=c++11, mais toujours -O0 -g et GAOL_DEBUGGING
1.8.0 à 1.8.3	NDEBUG et pas de GAOL_DEBUGGING (get_option('buildtype') y vaut release), mais -O0 -g
1.8.4, 1.8.5, 1.9.2, 1.10.1, 1.11.2	le release de GAOL : -O3, NDEBUG, les optimisations de configure, pas de GAOL_DEBUGGING

Avant 1.8.4, un sous-projet ne distingue pas le debug par défaut d'un --buildtype=debug demandé (vérifié : optimization, debug et buildtype y valent la même chose). À partir de 1.8.4, meson donne au sous-projet son propre type de build par défaut, et un --buildtype=debug demandé lui parvient (vérifié avec 1.8.4 et 1.11.2).

Correction (meson.build, gaol/meson.build) : dans un sous-projet, avec meson avant 1.8.4, on lit le type de build du projet dans les options optimization et debug, car de 1.8.0 à 1.8.3, get_option('buildtype') y lit le release de GAOL. Quand ces options sont celles du debug (optimization 0 et debug vrai) :

• les bibliothèques de GAOL et de CORE-MATH reçoivent override_options: ['optimization=3', 'debug=false', 'b_ndebug=true'] ;
• GAOL_DEBUGGING n'est pas défini, et les optimisations de configure (-funroll-loops…) s'ajoutent.

Si le parent demande release (optimization 3, debug faux), ces bibliothèques reçoivent b_ndebug=true, le if-release des default_options de GAOL. La relecture avait noté qu'avec 0.53.2 et --buildtype=release, GAOL n'avait pas NDEBUG. Les autres types de build demandés (debugoptimized, minsize, plain) sont gardés.

J'ai vérifié que override_options donne bien -DNDEBUG -O3 sur une cible, de 0.53.2 à 1.11.2. Les flags de gaol_interval.cpp après correction, mesurés avec 0.53.2, 0.57.2, 0.63.3, 1.3.2, 1.7.2, 1.8.0, 1.8.3, 1.8.4 et 1.11.2 :

• par défaut : -DNDEBUG -O3 -funroll-loops partout ;
• en --buildtype=release : la même chose ;
• en --buildtype=debugoptimized : -O2 -g, le choix du projet (de 1.8.0 à 1.8.3, meson y ajoute lui-même -DNDEBUG).

Deux cas gardent le type de build du projet, trouvés par la seconde relecture dans les sources de meson. Je les ai vérifiés à la lecture de ces sources, pas sous Windows :

• Visual C++ avec meson avant 0.57 : son debug donne /ZI /Ob0 /Od /RTC1 (msvc_buildtype_args), que cl refuserait avec le /O2 de optimization=3 (D8016). Forcer aussi buildtype=release changerait le runtime C de la cible (/MD contre le /MDd du projet). GAOL n'y force donc rien ;
• le backend Visual Studio de meson (--backend=vs) prend optimization et debug globalement pour toutes les cibles (vs2010backend.py).

Le prix : avant meson 1.8.4, un --buildtype=debug du projet ne compile plus GAOL pour le débogage. L'option enable-debug du troisième lot le fait, avec toutes les versions. doc/using.md le dit, ainsi que les deux cas ci-dessus.

CMake. J'y ai trouvé un défaut, avec un générateur à une seule configuration (Makefile, Ninja). Par add_subdirectory ou FetchContent sans CMAKE_BUILD_TYPE :

• libgaol ne recevait que -O3, sans NDEBUG ni les optimisations de Release (-funroll-loops -fomit-frame-pointer -fexpensive-optimizations, qui sont sous $<CONFIG:Release>) ;
• CORE-MATH, compilé à part (gaol_core_math, une bibliothèque OBJECT), n'avait aucune optimisation. Le commentaire de CMakeLists.txt et doc/building.md disaient le contraire.

Correction : sans type de build, gaol et gaol_core_math reçoivent -O3 (/O2 avec Visual C++), NDEBUG et les optimisations de Release que le compilateur accepte. Leurs commandes sont alors celles du Release (vérifié sur gaol_interval.cpp, exp.c et gaol_exact.c). Le build de tête ne change pas : il fixe Release lui-même. Avec un générateur à plusieurs configurations (Visual Studio, Ninja Multi-Config, Xcode), c'est cmake --build --config qui choisit, Debug sans --config. C'était déjà le cas avant, et doc/three-builds.md le dit maintenant.

autotools. Rien à changer. Un configure parent qui appelle celui de GAOL (AC_CONFIG_SUBDIRS([gaol])) donne -O3 -funroll-loops -fomit-frame-pointer -fexpensive-optimizations, -DNDEBUG et pas de GAOL_DEBUGGING, comme GAOL seul (vérifié).

Test. tests/release_flags.py <build> <sources de GAOL> vérifie, dans compile_commands.json, que chaque commande qui compile une source de GAOL ou de CORE-MATH (gaol/, 3rd/) a pour dernier -O un -O3 (ou /O2) et définit NDEBUG. Il vérifie aussi que le gaol_configuration.h du build laisse GAOL_DEBUGGING indéfini. Il sert deux fois :

• dans le test release de tests/meson_subproject, que le job de CI configure maintenant dans le type de build par défaut. Avec le meson 1.3.2 d'Ubuntu, le test a des dents dans la CI ;
• dans une nouvelle étape du job FetchContent de linux.yml : configurer tests/fetch_content sans type de build, puis lancer le script.

Vérifié : sans la correction, ces contrôles échouent.

• meson, avec gaol_release_options laissé vide : release_flags.py échoue avec meson 0.53.2, 1.7.2 et 1.8.0. Les 48 commandes de GAOL et de CORE-MATH y sont en -O0 ou sans optimisation (et, avant 1.8, sans NDEBUG).
• CMake, avec le CMakeLists.txt d'avant : release_flags.py échoue sur les 48 commandes (exp.c: optimization none, no NDEBUG, gaol_interval.cpp: no NDEBUG). Avec la branche : 0 sur 48.

Documentation.

• doc/using.md et le manuel : le type de build d'un sous-projet meson ;
• doc/building.md et le manuel : la phrase sur CMake sans type de build, et une phrase dans la table des options de meson ;
• doc/three-builds.md : le Release par défaut, en projet de tête ou amené par un autre ;
• doc/tests.md et doc/continuous-integration.md.

42. Le Python du Microsoft Store

Décidé le 3 octobre : adoucir le texte. Que WindowsApps contienne un alias python.exe en plus de python3.exe n'a jamais été vérifié sous Windows (#44 le tenait de la connaissance des alias, pas d'un test).

• doc/building.md : le paragraphe commence par « On Windows, none of what follows was checked, but read in the sources of meson », dit « python3.exe and perhaps python.exe too », et « meson 0.53.0 and earlier may take such an alias ». Les deux derniers points viennent de la relecture.
• meson.build : le commentaire au-dessus de version: dit la même chose (« 0.53.0 and earlier »).
• Le manuel : la même nuance. J'y ajoute le cas résiduel que donnait déjà doc/building.md : meson 0.53.1 et suivants n'écartent WindowsApps que si le PATH le nomme sous le répertoire de USERPROFILE, pas pour un profil dont le répertoire diffère.

J'ai relu le filtre _windows_sanitize_path() de meson 1.11.2 (programs.py) et de 0.53.2 (dependencies/base.py) : il compare chaque entrée du PATH à %USERPROFILE%\AppData\Local\Microsoft\WindowsApps. La relecture a vérifié qu'il manque à 0.52.1 et 0.53.0, et qu'il est là à partir de 0.53.1.

Comme confirmé le 3 octobre, l'ordre python3, python ne change pas.

52. La raison de C++17 dans les tests

tests/CMakeLists.txt, tests/Makefile.am (et son Makefile.in) et tests/meson.build justifiaient C++17 par les seuls littéraux de elementary_values.h. J'ai compilé chaque programme de tests/ (-fsyntax-only, GCC 9.4) :

• en -std=c++14 -pedantic-errors, tous échouent sur des littéraux flottants hexadécimaux, sauf u128.cpp (où -pedantic ne refuse que __int128), performance.cpp, refused_options.cpp et nodiscard.cpp ;
• en -std=gnu++14, qui accepte ces littéraux comme extension, tous compilent sans erreur ni avertissement : C++17 ne leur sert à rien d'autre.

gaol_tests.h, que tous les tests sauf u128.cpp incluent, en a un (0x1p-1060, l. 333). Hors commentaires et chaînes, 9 des 30 programmes en ont dans leur propre code : arithmetic, constants, core_math, elementary, fast_math_link, ieee1788, numbers, rounding_direction, static_initialization. Les *_values.h en ont des milliers. J'avais d'abord écrit « most of the programs » ; la relecture l'a relevé.

Les trois commentaires disent : « for the hexadecimal floating literals of the tests (those of gaol_tests.h, which all but u128.cpp include, of the *_values.h, and of several of the programs) ». Le Makefile.in est régénéré par automake 1.18.1, et son diff ne contient que ce commentaire.

65. Les open() de meson.build

Les trois programmes Python de meson.build (lecture de VERSION.txt, ses premiers octets, la détection de l'UTF-16) ouvrent maintenant le fichier avec with. Leurs lignes sont séparées par l'échappement \n des chaînes de meson, que 0.53.2 et 1.11.2 traduisent tous deux. Le runpython -c du meson.exe de 0.53 exécute le programme par exec(), qui accepte plusieurs lignes.

Sous CPython, le résultat ne change pas. Sous python3 -X dev, l'ancien code signale ResourceWarning: unclosed file <_io.TextIOWrapper name='VERSION.txt' ...> pour chacun des trois programmes, et le nouveau ne signale rien. .github/scripts/version-file.sh meson (BOM, CRLF, blancs, UTF-16 avec et sans marque, octet NUL…) donne 31 « ok » sur 31 avec meson 0.53.2 et avec 1.11.2. La relecture a comparé les trois programmes, ancien et nouveau, sous python3 -c et sous meson runpython -c (0.53.2 et 1.11.2), sur 9 fichiers : même sortie et même code de retour.

Le manuel et -lm

Décidé le 6 octobre : corrigé dans cette branche. Depuis #78, gaol.pc ne donne plus -lm. Le manuel disait encore :

• l. 832 : « GAOL is the only library to link, with the C mathematical library ». C'est devenu « GAOL is the only library to link: CORE-MATH […] is compiled into it, and the C++ compiler links the mathematical library of the system itself » ;
• l. 955 : que les Libs de gaol.pc donnent « GAOL itself with the C mathematical library ». C'est devenu « GAOL itself and the link option above ».

Troisième lot (décidé le 6 octobre, après la CI verte)

Après le premier compte rendu, vous avez tranché trois questions ouvertes : ajouter une option de debug, mettre pipefail dans #95, et Release par défaut avec un générateur CMake à plusieurs configurations (« Release par défaut seulement »).

pipefail. Toute étape des workflows qui envoie une commande dans tee commence maintenant par set -o pipefail : configurations et « Performance » de build-systems.yml, linux.yml et macos.yml. Les jobs Windows déclarent shell: bash dans leurs defaults, que GitHub lance en bash -eo pipefail : rien à changer. Dans les conteneurs (sh -c de Debian et d'Alpine, sans pipefail sûr), ./performance | tee fichier devient ./performance > fichier puis cat fichier, sous le set -e qui y est déjà.

L'option de debug (enable-debug pour meson, GAOL_DEBUG pour CMake). Elle compile les bibliothèques de GAOL et de CORE-MATH pour le débogage (sans optimisation, sans NDEBUG, avec GAOL_DEBUGGING), quels que soient le type de build ou la configuration, y compris dans un projet qui amène GAOL. Le code de ce projet, et les tests et les exemples de GAOL, gardent leurs propres drapeaux. configure --enable-debug ne change pas : un configure parent le transmet à celui de GAOL.

• meson (meson_options.txt, meson.build) : enable-debug revient, avec ce sens. Il passe avant le Release forcé des sous-projets ; les bibliothèques reçoivent override_options: ['optimization=0', 'debug=true', 'b_ndebug=false']. En sous-projet : -Dgaol:enable-debug=true, ou default_options: ['enable-debug=true'] dans subproject() ou dependency() (vérifié avec 0.53.2 et 1.11.2). Les tests et les exemples gardent les optimisations de configure (-funroll-loops…), qui restent sans effet sur les bibliothèques en -O0.
• CMake (CMakeLists.txt) : option(GAOL_DEBUG ... OFF).
  • GAOL_DEBUGGING est défini dans gaol_configuration.h ;
  • les optimisations de Release (-funroll-loops…) ne sont pas ajoutées ;
  • à la fin du CMakeLists.txt de tête, chaque CMAKE_<LANG>_FLAGS_<CONFIG> de ce répertoire perd ses drapeaux d'optimisation et NDEBUG (-O*, /O*, /Ob*, -DNDEBUG) et gagne -O0 -g (/Od /Ob0 avec Visual C++). Sans type de build, -O0 -g s'ajoute à CMAKE_<LANG>_FLAGS. Les autres drapeaux de la configuration restent : runtime C de Visual C++, sanitizers, macros du projet. GAOL s'édite donc toujours avec le code de cette configuration ;
  • avec Visual C++, l'information de débogage vient de MSVC_DEBUG_INFORMATION_FORMAT (ProgramDatabase) si CMP0141 est NEW (CMake 3.25 et suivants), et de /Zi sinon ;
  • CMake prend pour une cible les drapeaux de son répertoire tels qu'ils sont à la fin : gaol et gaol_core_math les reçoivent, tandis que tests/ et examples/, ajoutés avant, et le projet parent gardent les leurs. gaol_bench, dans le même répertoire, les recevrait aussi : la cible perf n'existe pas avec GAOL_DEBUG, ni avec enable-debug, qui mesureraient un GAOL de débogage.
• Vérifié, configuration seule, avec tests/release_flags.py --debug :
  • CMake : GAOL seul en Release, FetchContent sans type de build et en Release, Ninja Multi-Config. Les trois configurations y donnent -g sans -O ni NDEBUG ;
  • meson : 0.53.2 et 1.11.2 seul, et 0.53.2, 1.7.2, 1.8.0 et 1.11.2 en sous-projet ;
  • dans le build CMake de tête avec GAOL_DEBUG, tests/arithmetic.cpp garde -O3 -DNDEBUG.
• Construit et testé : CMake avec GAOL_DEBUG=ON (tests seuls), ctest 41 sur 41 ; meson 0.53.2 avec -Denable-debug=true et les tests, 29 réussis et 2 sautés ; CMake SSE2 par défaut, 57 sur 57 ; l'audit des trois builds, la même configuration ; le manuel, sans erreur.
• Le nom : GAOL_DEBUG(lvl, cmd) est aussi une macro de GAOL (gaol/gaol_common.h, manuel l. 5006). L'option CMake ne passe jamais au compilateur, donc rien ne se heurte, mais les deux noms peuvent prêter à confusion (voir les questions ouvertes).

Plusieurs configurations (« Release par défaut seulement »). GAOL projet de tête, avec un générateur à plusieurs configurations (Visual Studio, Xcode, Ninja Multi-Config), met Release en tête de CMAKE_CONFIGURATION_TYPES, sauf si la liste est donnée en ligne de commande ou dans l'environnement. Ce dernier cas se repère avant project().

• Ninja Multi-Config construit alors Release par défaut. Vérifié : Release;Debug;RelWithDebInfo, et ninja -n ne construit que CMakeFiles/gaol.dir/Release/ ; sur configure-clean, c'était Debug/. Une liste donnée (Debug;Release) est gardée.
• cmake --build avec Visual Studio construit Debug sans --config, comme le choisit CMake ; non vérifiable ici, pas plus que ce que montrent les IDE.
• En sous-projet, c'est la configuration du parent qui décide. La documentation le dit.

Tests de la CI.

• Le nouveau job build-types de linux.yml, en configuration seule :
  • GAOL_DEBUG avec GAOL seul et par FetchContent, sans type de build et en Release (release_flags.py --debug) ;
  • un contrôle que les tests de GAOL et du projet gardent leurs drapeaux, et que GAOL garde ceux de la configuration sans prendre ceux de Debug. Le FetchContent en Release y porte -DPROJECT_RELEASE dans ses drapeaux Release et -DPROJECT_DEBUG dans ses drapeaux Debug ;
  • le Release par défaut de Ninja Multi-Config.
• Une étape de plus dans les deux jobs meson-subproject : -Dgaol:enable-debug=true en sous-projet, et -Denable-debug=true seul.
• J'ai rejoué ces étapes en local (CMake 4.4, meson 1.3.2 et 1.11.2).
• release_flags.py tient compte de l'ordre des drapeaux : un -UNDEBUG après -DNDEBUG. Il accepte GAOL_DEBUGGING dans gaol_configuration.h ou sur la ligne de commande. Chaque contrôle échoue dans le sens contraire (vérifié).

Documentation.

• doc/building.md : les tables des options de CMake, de configure et de meson, et celle des macros ; une phrase sur le multi-configuration ;
• doc/three-builds.md, doc/using.md, le manuel (listes et tables des options, partie Debugging, partie CMake), doc/tests.md et doc/continuous-integration.md.

Quatrième lot (décidé le 6 octobre)

La macro GAOL_DEBUG(lvl, cmd) devient GAOL_DEBUG_VERBOSE(lvl, cmd). L'option CMake garde le nom GAOL_DEBUG, qui suit le schéma GAOL_SIMD / enable-simd.

• Renommée partout : gaol/gaol_common.h (sa définition), ses 96 usages dans gaol/gaol_expression.h et gaol/gaol_expression.cpp, et tests/debugging.cpp.
• Le manuel (defmacroA, avec l'ancien nom et \newinvfive), doc/building.md et doc/tests.md suivent.
• Aucun alias pour l'ancien nom, comme pour les macros renommées au point J : un GAOL_DEBUG laissé dans un programme ne compile plus.
• manual/v4 et les registres ne changent pas.

L'option d'édition de liens de gaol_dep. check_flags.py (test flags de tests/meson_subproject) lit aussi, dans build.ninja, la commande d'édition de liens de chaque exécutable du projet, hors de subprojects/. Elle doit contenir les options des Libs du gaol.pc du sous-projet, -L et -l à part : -mno-daz-ftz là où le compilateur le prend, donc avec le GCC 13 de la CI. Avec un compilateur qui le refuse (GCC 9.4, Clang 18), il n'y a rien à vérifier, et le test le dit.

Vérifié : ce contrôle échoue sans le link_args: gaol_link_args de gaol_dep. Aucun compilateur d'ici ne prend -mno-daz-ftz ; je l'ai montré avec un enveloppeur de g++ qui accepte l'option et la retire :

• avec la branche : « 6 link(s) of the project checked for -mno-daz-ftz » ;
• sans le link_args : « gaol_test_reverse is linked without -mno-daz-ftz », et les autres exécutables de même.

Les branches distantes déjà fusionnées du « Ménage » (todo-27-per-instruction-rounding, todo-d-headers, todo-d21-integers, todo-g-refused-options, todo-m-tan, todo-r-atanh-hausdorff) n'existaient déjà plus sur GitHub quand j'ai voulu les supprimer. Il ne reste que todo-12-long-sums (E), todo-o-meson et todo-u-small-errors.

Vérifié en local : CMake SSE2, 57 sur 57 ; headers.sh sur le GAOL installé (79 macros, toutes préfixées GAOL_ ou gaol_) ; GAOL_DEBUG avec -Wall -Wextra -Werror, qui compile les usages renommés sous GAOL_DEBUGGING, 41 sur 41 ; tests/meson_subproject avec meson 0.53.2, 8 sur 8 ; le manuel, sans erreur.

Pour doc/differences.md et ChangeLog (pull request de synthèse)

• doc/differences.md, partie meson : « GAOL can be a subproject of a meson project (dependency('gaol', fallback: ['gaol', 'gaol_dep'])): meson.build gives its flags with add_project_arguments(), gaol_dep gives the code using GAOL the flags of interval arithmetic of gaol.pc, and a subproject declares no test setup. meson refused the add_global_arguments() it called in a subproject. As a subproject, GAOL is built in release by default, even with meson before 1.8.4, which gives it the build type of the project. »
• doc/differences.md, partie CMake : « Brought in by a project without a build type (add_subdirectory, FetchContent), GAOL and CORE-MATH are compiled as in Release: -O3, NDEBUG and the optimizations of configure. GAOL had -O3 alone, and CORE-MATH no optimization. »
• ChangeLog : « meson.build, gaol/meson.build: add_project_arguments() rather than add_global_arguments(), which meson refuses in a subproject, gaol_dep carries the flags of interval arithmetic (pc_cflags), no test setup nor target check in a subproject, and the libraries in release in a subproject where meson before 1.8.4 gives the debug of the project; tests/meson_subproject and a job of build-systems.yml check it. »
• ChangeLog : « CMakeLists.txt: without a build type, gaol and gaol_core_math are compiled as in Release (-O3, NDEBUG, -funroll-loops...); tests/release_flags.py checks it on tests/fetch_content in linux.yml. »
• doc/differences.md, parties CMake et meson : « GAOL_DEBUG (CMake) and enable-debug (meson, which had defined GAOL_DEBUGGING alone and was gone) build libgaol and CORE-MATH for debugging whatever the build type or the configuration, a project bringing GAOL in included. With a generator of several configurations, GAOL built alone puts Release first among them. »
• ChangeLog : « CMakeLists.txt: GAOL_DEBUG, and Release first among the configurations of a generator of several. meson_options.txt, meson.build: enable-debug. tests/release_flags.py --debug, the job build-types of linux.yml. .github/workflows: set -o pipefail in the steps piping into tee. »
• doc/differences.md : « The macro GAOL_DEBUG(level, command) is named GAOL_DEBUG_VERBOSE: GAOL_DEBUG is the option of CMake that builds GAOL for debugging. »
• ChangeLog : « gaol/gaol_common.h: GAOL_DEBUG(lvl, cmd) renamed GAOL_DEBUG_VERBOSE. tests/meson_subproject/check_flags.py: the link option of gaol.pc too. »
• ChangeLog : « meson.build: the files Python reads VERSION.txt from are closed (with). doc/building.md, manual: the python.exe alias of WindowsApps is not checked on Windows. tests/: C++17 for the hexadecimal floating literals of the tests, not of elementary_values.h alone. manual: gaol.pc names no mathematical library. »

Relecture

Un sous-agent indépendant a relu les six premiers commits. Il a reconstruit et relancé lui-même, dans des copies (meson 0.53.2 à 1.11.2, automake 1.18.1, pdflatex).

Il a trouvé deux points bloquants, que j'ai vérifiés puis corrigés :

• le add_test_setup(..., is_default: true) de GAOL dans un sous-projet (voir le 41) ;
• « most of the programs », faux (voir le 52).

Ses remarques mineures, aussi vérifiées puis corrigées :

• meson.build_root(), déprécié depuis meson 0.56, remplacé par meson.current_build_dir() ;
• l'absence de pipefail dans le job ;
• tar -h qui suit le lien sans fin ;
• « 0.53.0 » devenu « 0.53.0 and earlier » ;
• doc/building.md, qui affirmait encore « take » ;
• tests/meson_subproject absent de la phrase de doc/tests.md sur le délai de numbers ;
• README.md ;
• deux paragraphes mal coupés.

Ce qu'il a vérifié et trouvé juste :

• l'échec de la base ;
• le sous-projet avec 20 versions de meson ;
• les dents de flags ;
• le tableau des types de build ;
• la recette dependency(..., fallback:) ;
• le 65, sur 9 fichiers ;
• version-file.sh (31 sur 31) ;
• le filtre WindowsApps ;
• le build de tête inchangé hors des exemples ;
• tests/Makefile.in régénéré à l'identique ;
• CPack et .gitignore ;
• le manuel ;
• les messages de commit et les fichiers à ne pas toucher.

Non repris : contrôler aussi l'option d'édition de liens de gaol_dep (-mno-daz-ftz). Elle n'est pas dans compile_commands.json, et cette partie de gaol_dep existait avant la branche.

Le même sous-agent a ensuite relu les neuf commits suivants : B1, B2, le Release par défaut et le manuel. Il a trouvé un point bloquant :

• B3 : Visual C++ avec meson avant 0.57 (voir plus haut), lu dans les sources de meson. Il n'est plus forcé, et c'est documenté.

Ses remarques mineures, vérifiées puis corrigées :

• le elif release qui, de 1.8.0 à 1.8.3, valait aussi pour debugoptimized ;
• le débogage d'un sous-projet avant 1.8.4, à dire dans doc/using.md ;
• le backend Visual Studio de meson ;
• les générateurs CMake à plusieurs configurations ;
• une phrase de l'en-tête de tests/meson_subproject devenue fausse après l'exclusion de version-file.sh ;
• la variante apt, qui ne vérifiait pas son meson ;
• le motif -O de release_flags.py, qui prenait aussi /Ob2 (devenu ^[-/]O([0-3sgdxz]|fast)?$) ;
• « (-O0 -g) », faux avant 0.63 ;
• un sujet de commit de 101 caractères.

Ce qu'il a vérifié et trouvé juste :

• B1 et B2 corrigés, avec leurs dents ;
• la logique meson avec 18 versions, et les autres types de build ;
• les tests de GAOL dans le sous-projet (-Dgaol:with-tests=true) : 53 réussis ;
• la variante apt (meson 1.3.2 : meson compile, puis 8 sur 8) ;
• CMake (98 commandes de tête identiques, FetchContent sans type de build, l'étape de la CI vraiment sans type de build) ;
• autotools ;
• version-file.sh avec le lien présent (31 sur 31) ;
• le manuel ;
• les commits.

Il n'a pas pu vérifier le --exclude=./... avec le tar BSD de macOS.

Une troisième relecture, sur les six commits du troisième lot, a trouvé un point bloquant :

• B4 : la première version de GAOL_DEBUG recopiait tels quels les drapeaux Debug du projet dans les autres configurations de GAOL. Ce que le projet y met n'arrivait alors que dans GAOL. Avec -DCMAKE_BUILD_TYPE=Release -DGAOL_DEBUG=ON "-DCMAKE_CXX_FLAGS_DEBUG=-g -fsanitize=address", gaol_test_reverse ne s'éditait pas (références indéfinies à __asan_*). Avec Visual C++ et CMP0091 OLD, le /MDd du Debug irait dans les objets Release de GAOL (LNK2038, lu dans les sources de CMake).
• Corrigé comme décrit plus haut. Avec la correction, le même cas se construit et gaol_test_reverse passe (4 089 vérifications, 0 échec). Avec l'ancien bloc, le nouveau contrôle de la CI échoue sur gaol_interval.cpp (vérifié).

Ses remarques mineures, corrigées :

• gaol_bench et la cible perf ;
• l'information de débogage de Visual C++ sous CMP0141 ;
• les optimisations de configure des tests sous enable-debug ;
• le contrôle de la CI ;
• la ligne de la table des macros, qui dit maintenant « the macro GAOL_DEBUG(level, command) » ;
• la nuance de --enable-debug en sous-paquet ;
• l'affirmation non vérifiée sur les IDE, retirée.

Ce qu'il a vérifié et trouvé juste :

• les drapeaux pris au répertoire de la cible, à la fin (Ninja, Makefile, Ninja Multi-Config ; FetchContent en Release, sans type, RelWithDebInfo, MinSizeRel, Debug) ;
• GAOL_DEBUG désactivé, qui ne change rien (98 sur 98 commandes de tête, 55 sur 55 par FetchContent) ;
• le réordonnancement des configurations (gardé après une reconfiguration ; une liste ou un CMAKE_DEFAULT_BUILD_TYPE donnés sont respectés) ;
• enable-debug avec meson 1.3.2, 0.53.2 et 1.11.2 ;
• release_flags.py dans les deux sens ;
• le YAML et pipefail, y compris l'absence d'autre tube cassé ;
• les commits.

Remarques laissées : avec meson 0.53 à 0.56 et Visual C++, enable-debug ne donne pas /Zi (msvc_debug_args[True] y est vide) ; non vérifiable sans Windows, comme le comportement des IDE.

Vérifié en local

Sur ce portable (i7-1185G7, GCC 9.4, Clang 18), sur une copie des fichiers de la tête de la branche :

• CMake SSE2, FPU et Clang 18, avec tests et exemples : ctest -j4, 100 % de 57 (intervalf et interval2f sautés) ;
• -Wall -Wextra avec CMAKE_COMPILE_WARNING_AS_ERROR=ON, GCC et Clang : construits sans avertissement ;
• autotools (configure --with-tests --with-examples, make, make install, make check) : 29 tests réussis et 2 sautés, 16 exemples réussis ; make distclean rend l'arbre ;
• meson 0.53.2 (with-tests, with-examples) : 45 réussis, 2 sautés ; meson 1.11.2 : 29 réussis, 2 sautés (les exemples ne sont pas dans la configuration de test par défaut) ;
• .github/scripts/tests.sh sur le GAOL installé par meson : 292 728 vérifications, 0 échec ;
• tests/meson_subproject, type de build par défaut : 8 sur 8 avec meson 0.53.2, 1.3.2, 1.7.2, 1.8.0, 1.8.4 et 1.11.2, et avec 0.53.2 en --buildtype=release ;
• tests/fetch_content configuré sans type de build : tests/release_flags.py, 48 commandes de GAOL et de CORE-MATH en Release ;
• les builds de tête inchangés, compile_commands.json comparé à celui de configure-clean aux mêmes chemins : CMake, 0 sur 98 ; meson, les 16 exemples seulement ;
• .github/scripts/version-file.sh meson : 31 sur 31 avec 0.53.2 et avec 1.11.2 ;
• .github/audit (audit.sh puis compare.py --check) : « the same configuration in: cmake, autotools, meson » ;
• package_source de CPack (voir le 41) ;
• le manuel, deux passes de pdflatex : aucune erreur, 129 pages, le même unique Overfull \hbox (l. 537-541) que sur configure-clean ;
• après les corrections de la seconde relecture, qui ne touchent que meson.build, les scripts de test et la documentation : les commandes du build meson de tête, revérifiées (0.53.2 et 1.11.2 : les 16 exemples seulement) ; les flags du sous-projet par version et par type de build (ci-dessus) ; tests/meson_subproject avec meson 1.3.2, 8 sur 8 ; le manuel, de nouveau ;
• check_branch : OK.

Non vérifiable ici :

• les deux jobs meson-subproject eux-mêmes (meson de pipx et meson 1.3.2 d'Ubuntu 24.04), et l'étape FetchContent sans type de build de linux.yml ;
• le sous-projet sous Windows et macOS, et le CMake sans type de build avec Visual C++ et Ninja (/O2, NDEBUG) ;
• le contenu de WindowsApps et le filtre de meson sous Windows : je n'ai fait que relire le filtre.

Dépendances

Aucune.

Questions ouvertes

• tests/performance.cpp est compilé en C++17 dans les trois builds sans en avoir besoin (pas de littéral hexadécimal, il compile en C++14). Je n'y ai pas touché.
• Remarqué, sans effet : avant meson 0.63, un GAOL sous-projet est compilé avec la norme C++ du projet (ou celle du compilateur), pas -std=c++11.
• Non vérifiable ici, accepté et documenté (décidé le 6 octobre) : Visual C++ avec meson avant 0.57, et le backend Visual Studio de meson, gardent le type de build du projet pour un GAOL sous-projet. GAOL_DEBUG avec Visual C++ n'est pas vérifié non plus.