E.T. téléphone Meson

Posté par Collectif le 07 octobre 2018 à 21:44. Édité par Julien Jorge, Davy Defaud, bubar🦥, Benoît Sibaud, ZeroHeure et Bruno Michel. Modéré par Pierre Jarillon. Licence CC By‑SA.

Étiquettes :

oct.

2018

Meson est une technologie récente de la catégorie des systèmes de configuration et de gestion de la compilation de projets, à l’instar d’Autotools et de CMake. Nous proposons dans cette dépêche un tour de Meson, avec une explication des technologies en jeu, puis des comparaisons et quelques tests de rapidité et performance. En aucun cas nous ne tomberons dans le cassage des autres technologies et nous essaierons de comparer de manière la plus neutre possible.

Meson a été initié par Jussi Pakkanen en 2013. Frustré par Autotools, insatisfait par CMake, il a décidé de s’attaquer au problème et défini les buts à atteindre. Meson est le fruit de son travail, aidé de la communauté de contributeurs qui s’est formée.

Bien entendu, nous ne sommes pas omniscients et attendons des commentaires pertinents des lecteurs de LinuxFr.org pour corriger toute erreur, dans la joie et la bonne humeur.

Sommaire

Culture et Histoire
Chérie, j’ai les mêmes à la Meson ?
- Vous avez dit Ninja ?
- Pourquoi ninja est‐il plus rapide que make ?
Construire un projet avec Meson
Comparaisons et discussions sur les qualités de meson
Exemples de projets portés sur meson
Conclusion

N. D. M. : Cette dépêche est une reprise à partir d’une version longtemps restée inchangée dans l’espace de rédaction, ça arrive. :-) La liste des contributeurs est donc réellement la suivante : Jehan, et 16 autres : Anonyme, BAud, Olivier Humbert, palm123, _PhiX_, Cyril Brulebois, Storm, Marco, David Marec, dourouc05, ZeroHeure, vpinon, Bruno Michel, Oliver H, Boiethios et Snark.

Culture et Histoire

Au commencement le compilateur était bien seul

Quand vous souhaitez compiler un logiciel très simple, disons juste un fichier source, en général, vous ne vous embêtez avec aucun des logiciels précités. Vous sortez juste votre compilateur préféré et en une ligne de commande, vous avez votre exécutable :

gcc main.c

Même avec plusieurs fichiers, parfois on va juste enchaîner les quelques fichiers sur une ligne de commande unique et mettre le tout dans un script shell. Allez, avouez, vous avez tous fait ça un jour. Mais si, vous savez, pour votre premier jet, avant de faire votre premier commit ! Faut pas rougir !

Dans le monde des logiciels libres, les deux compilateurs les plus souvent rencontrés sont le vénérable GCC et Clang/LLVM.

Puis vint le Makefile

make propose une syntaxe de définition d’éléments de compilation dans les fichiers Makefile.

Ce format a permis de segmenter une compilation compliquée en éléments de plus petite taille. Mais surtout, il a ajouté des notions de dépendances et de compilation conditionnelle. Ainsi, la commande make ne recompile que les parties dont les fichiers sources ont été modifiés, accélérant considérablement la compilation par rapport à une compilation totale.

Chaque machine est potentiellement différente, il faut donc adapter : où installer les binaires ? Et les fichiers de données ? Ah, tu veux utiliser un autre compilateur que gcc ? Selon que tu compiles sous GNU/Linux, BSD, Windows ou macOS, tu as besoin de compiler des fichiers différents ? Ton code a besoin de savoir si la machine cible a telle API disponible ? Certaines fonctionnalités sont optionnelles ? etc.

Cette configuration est possible avec make, mais cela rend les Makefile compliqués à l’extrême. C’est là que sont nés les Autotools.

Et enfin les Autotools

Les trois principaux outils d’autotools sont autoconf, autoheader et automake.

autoconf, par exemple, va créer un fichier de configuration adapté au projet (le fameux ./configure), et automake génèrera les scripts Makefile à partir de modèles utilisant une syntaxe similaire, de plus haut niveau.

L’une des avancées majeures des autotools est la standardisation des logiciels qui en est née (voir la section Makefile Conventions des GNU Coding Standards).

Cette standardisation segmente le type de données (exécutables, bibliothèques, données du système, données du logiciel, données de l’utilisateur, configuration, etc.) et définit divers emplacements : exécutables dans /bin, données du système dans /share, configurations dans /etc…

Il y eut également une standardisation des fonctionnalités de base attendues d’un système de compilation, avec des cibles/actions par défaut (par exemple, l’installation, la désinstallation, les tests unitaires, le nettoyage de fichiers construits), ainsi que de nombreuses options par défaut (pour la compilation croisée, les compilations hors de l’arbre des sources, la gestion fine des divers chemins d’installation, etc.)

Enfin, cela a standardisé les règles de compilation et d’installation avec les concepts de « préfixe », « datadir », « DESTDIR », etc. Les gens savaient à quoi s’attendre et compiler un logiciel utilisant le fameux triptyque ./configure && make && make install. À tel point que le fichier INSTALL est désormais généré par les Autotools (s’il n’existe pas, car toute installation autotools a une base similaire).

Chérie, j’ai les mêmes à la Meson ?

Meson ne prend pas make en charge. C’est un choix de conception et utilise Ninja (développé pour s’affranchir des contraintes historiques de Make).

Vous avez dit Ninja ?

Meson est souvent mis en avant pour sa rapidité de construction, mais elle est surtout due à ninja, globalement plus performant que make. En effet, les fichiers que lit ninja pour la construction ne contiennent pas de script, là où make peut être amené à réévaluer des portions de code (portions de code shell embarqué dans un Makefile par exemple).

Nous vous conseillons la lecture des raisons qui ont motivé la création de Ninja.

Pourquoi ninja est‐il plus rapide que make ?

Les raisons sont principalement historiques. La première raison est que le format Makefile fut créé pour être écrit originellement à la main (les Autotools sont nés après). Le langage a donc toutes les fonctionnalités possibles et imaginables qui auraient pu être nécessaires dans l’histoire du développement d’applications.

Le projet Ninja a fait le choix dès le début de n’avoir presque aucune fonctionnalité, sinon les plus basiques, dans les fichiers ninja eux‐mêmes :

Original : « In contrast, Ninja has almost no features; just those necessary to get builds correct while punting most complexity to generation of the ninja input files. »

Traduction : « En comparaison [de Make], Ninja n’a presque aucune fonctionnalité : seulement le strict nécessaire pour compiler correctement en déplaçant la complexité durant la génération des fichiers d’entrée Ninja. »

En particulier, on parle là de fonctionnalités décisionnelles. Même si l’étape de configuration existe avec le triptyque autotools, elle va principalement créer des variables qui seront utilisées ensuite dans les scripts Makefile. Il y a donc en réalité toujours beaucoup de code « décisionnel » exécuté lors du make. De son côté, ninja étant fait dès le début pour ne jamais être utilisé directement, ils ont délégué, par design, la plupart des décisions au script de configuration. Cela peut éventuellement amener à des scripts ninja plus verbeux et moins évidents à lire, mais néanmoins plus rapides.

Ninja se repose donc entièrement sur les projets de type meson pour gérer la partie décisionnelle, comme le manuel le dit lui‐même en conclusion de l’extrait précédent :

Original : « Ninja by itself is unlikely to be useful for most projects. »

Traduction : « Ninja, en soi, a peu de chance d’être utile à la plupart des projets. »

Alors qu’il est toujours possible, bien que déconseillé, de créer des fichiers Makefile à la main, un projet qui utilisera ninja le fera indirectement (avec cmake ou meson).

Construire un projet avec Meson

Configuration

Le projet Meson en fait une seule étape et demande donc à tout le monde d’installer meson.

Là où les Autotools faisaient :

/chemin/vers/sources/configure --prefix=/mon/prefix --enable-some-option

… Meson fait :

meson /chemin/vers/sources/ --prefix=/mon/prefix -Dsome-option=true

Les options de compilation se passent aussi sur cet appel. Pour reconfigurer, avec Autotools, il faut utiliser la même commande à nouveau. Avec meson, on doit utiliser :

meson configure -Dprefix=/autre/prefix -Dsome-option=false

Enfin pour voir seulement les options configurées, ce qui n’est pas faisable facilement avec les Autotools, on peut lancer :

meson configure

Notons que si vous avez mis à jour meson entre deux configurations, vous risquez d’obtenir l’erreur suivante :

$ meson configure
Meson configurator encountered an error:

Version mismatch (0.44.1 vs 0.44.0)

(voir le rapport de bogue)

Compilation/construction

Cette partie remplace simplement make par ninja.

Installation

Là aussi, le make install est simplement remplacé par ninja install.

Autres cibles classiques

make uninstall (Autotools seulement, absent de CMake par conception) est remplacé par ninja uninstall ;
make check (Autotools) ou make test (CMake) est remplacé par meson test ;
make dist et make distcheck (Autotools seulement, absent de CMake) n’existent pas ;
make clean (Autotools et CMake) est remplacé par ninja clean ;
make distclean (Autotools seulement) n’existe pas (avec une compilation hors sources, cela peut sembler moins nécessaire puisque l’on peut aussi supprimer entièrement le répertoire de compilation ; mais en réalité, make distclean est un nettoyage en profondeur et néanmoins contrôlé qui peut permettre de garder certains fichiers que l’on aurait rajoutés par exemple).

Meson génère également des projets pour deux environnements de développement intégré (EDI/IDE) répandus :

Visual Studio (compatibilité Windows) ;
Xcode (compatibilité macOS).

Sortie standard

Un travail a été fait sur la sortie standard, aussi bien de la configuration que de la compilation, notamment sur les couleurs, mais aussi pour la rendre plus claire et donc lisible. Un travail similaire avait aussi été fait dans CMake, ce qui est un des points agréables de ces deux systèmes de compilation. Cela est particulièrement utile pour la lecture d’erreurs de compilation.

Ainsi, lors de la compilation, ce type de sortie est affiché :

[292/912] Compiling C object 'gobject/tests/object@exe/object.c.o'

Et au lieu d’imprimer les sorties les unes au‐dessous des autres, la sortie précédente est effacée, permettant d’éviter les défilements trop longs et de se concentrer sur le dernier élément. En outre, le compteur d’étape est agréable pour savoir où l’on en est dans la compilation (particulièrement pour les très gros projets aux longues compilations).

Enfin, il est possible d’afficher la configuration actuelle grâce à la commande meson configure (avec les Autotools notamment, hormis si le projet implémente cela explicitement, il faut lire la sortie peu lisible de ./configure ou le fichier config.log). Meson n’est pas parfait non plus, mais n’en est pas loin, car il est utile de visualiser cet affichage de configuration lors de tout changement de ladite configuration :

meson configure -Dsome-option=true
meson configure

Notons que CMake a une interface curses extrêmement cool — ccmake — et qu’idéalement il faudrait que Meson crée une interface similaire (travail en cours). Cette interface permet d’avoir constamment une vision d’ensemble des options d’un projet.

Comparaisons et discussions sur les qualités de meson

Les avancées

La rapidité de ninja ne fait cependant pas tout. Parlons maintenant de Meson.

L’une des premières bonnes choses que l’on remarque est que Meson est dans une optique de standardisation de la compilation (malgré encore quelques incohérences), une chose que l’on avait un peu perdue avec CMake, qui semblait encourager les projets à redoubler d’originalité sur les options et les fonctionnalités de compilation (cette tendance s’est un peu calmée et les projets utilisant CMake se sont beaucoup standardisés ces dernières années grâce au module GNUInstallDirs, mais les premières années étaient plutôt terribles sur ce point, dans la gestion des options, mais aussi l’absence des cibles de compilation standards, par exemple pour désinstaller un paquet, nettoyer un répertoire de compilation…) !

On remarque aussi que le projet Meson semble vouloir encourager les bonnes pratiques qui se sont créées à travers l’histoire de la compilation de projet. Ainsi les warnings de compilation sont activés par défaut, et surtout les compilations hors de l’arbre des sources (aussi appelées compilations VPATH dans les Autotools) sont rendues obligatoires. Il ne s’agit pas là de fonctionnalités nouvelles ou exceptionnelles, puisqu’elles existent et sont utilisées massivement dans les projets utilisant Autotools ou CMake, mais il est intéressant de voir que le système de compilation fait le choix de proposer par défaut ces pratiques, plutôt que d’attendre des projets ou des gens de les appliquer.

Un autre apport de Meson est la gestion des en‐têtes précompilés, qui ajouterait plus de rapidité à l’étape de compilation et expliquerait partiellement que la compilation avec Meson serait plus rapide que d’autres systèmes de compilation utilisant aussi Ninja, comme CMake.

Enfin l’une des autres qualités appréciables est le faible nombre de dépendances à l’heure actuelle, à savoir : Python 3 et Ninja uniquement.

Des reculs ?

Cette section et la suivante sont un retour d’expérience d’utilisation de Meson sur des projets.

La compilation croisée semble avoir connu un recul. Les Autotools sont extrêmement bien pourvus en ce sens, une logique d’exécution sans faille avec les notions de « nom canonique » pour host, build et target. Ces notions combinées avec une très bonne détection des plates‐formes (script config.guess), permettent d’exécuter une compilation croisée avec uniquement le nom canonique de la plate‐forme cible, et les outils de compilation adéquats préfixés par ce nom canonique. Malheureusement, Meson semble avoir choisi l’approche de CMake, qui consiste en la création d’un fichier ’environnement rempli d’informations redondantes.

Ainsi, prenons ce fichier typique pour la compilation croisée pour Windows 32 bits, utilisé dans l’outil de compilation croisée, crossroad :

[binaries]
c = 'i686-w64-mingw32-gcc'
cpp = 'i686-w64-mingw32-g++'
ar = 'i686-w64-mingw32-ar'
strip = 'i686-w64-mingw32-strip'
pkgconfig = 'i686-w64-mingw32-pkg-config'

[host_machine]
system = 'windows'
cpu_family = 'x86'
cpu = 'i586'
endian = 'little'

Comme vous le notez, toutes ces informations sont entièrement redondantes et pourraient être résumée en une chaîne de caractères unique : « i686-w64-mingw32 ».

Les divers binaires par exemple sont tous préfixés du nom canonique de la plate‐forme, ce qui est tout simplement le standard à l’heure actuelle pour les outils de compilation croisée. En fait, les lister explicitement est même prompt à créer des bogues, puisque si l’on a oublié de lister un outil, Meson se rabattra sur la version non préfixée, alors même que la version préfixée existerait et serait installée. Ainsi, mon fichier est en fait incomplet, et si l’on tombait sur un projet particulier nécessitant des binaires moins communs, par exemple nm, Meson ne le trouverait pas car il n’a pas été listé, alors que x86_64-w64-mingw32-nm est pourtant bien installé sur la machine.

Quant aux informations sur le système, le processeur et le boutisme (endianness) du processeur, elles sont aussi contenues dans le nom canonique (puisqu’ils sont standardisés) et sont tout aussi redondantes.

De leur côté, les Autotools effectuent la compilation croisée avec seulement ce type de configuration :

./configure --host=x86_64-w64-mingw32

L’ensemble des informations est contenu dans cette chaîne de caractères avec la base de connaissance des plates‐formes connues, et cela évite les oublis et erreurs dans la maintenance d’un fichier à part. Notamment, par défaut, le script ./configure sélectionne toute variante dédiée à la compilation automatique et se rabat sur la version native en cas de non‐existence. Ainsi, PKG_PROG_PKG_CONFIG() utilise x86_64-w64-mingw32-pkg-config, s’il existe, et pkg-config autrement. Bien sûr, comme pour tout, il est toujours possible de passer outre les comportements par défaut, ce qui permet aussi de reproduire l’équivalent du fichier de compilation croisée au besoin, par exemple si vous utilisez des outils ou un environnement peu standard (mais, par défaut, Autotools considère que votre environnement est standard).

Il s’agit d’un choix étonnant de la part du projet Meson, puisque l’approche « à la CMake » cause quelques soucis. Il s’agit cependant d’un choix assumé, comme le confirment les développeurs dans un rapport de bogue, car les outils préfixés seraient une approche trop « GNU‐centrique ».

Enfin, malgré le choix de suivre l’esprit des Autotools en prenant en charge les cibles standards courantes, certaines cibles ont tout de même disparu. On pense notamment à make dist et make distcheck, deux cibles extrêmement importantes pour la solidité d’une archive TAR de sortie.

Meson exige donc un soin particulier à la réalisation des fichiers d’environnement, ceci peut être vue comme une qualité ou un défaut, à chacun de juger. Il y a néanmoins certaines informations que l’on ne peut considérer que comme redondantes, mais qui (pour le moment ?) sont nécessaires.

On veut des chiffres !

Pour l’étape de configuration en particulier, en utilisant le dépôt de glib qui contient maintenant autotools et meson, un simple test semble montrer vingt secondes de configuration avec les Autotools (./configure) et dix secondes avec Meson (meson).

Meson montre vraiment un grand avantage sur la reconfiguration (changer certains paramètres de configuration) : celle‐ci est quasiment instantanée avec Meson alors qu’elle prend le même temps que la première configuration avec les Autotools et CMake.

Ainsi, sur ce petit exemple de la compilation de glib, on constate une compilation de binaires durant 3 min et 40 s avec les scripts Makefile générés par Autotools, et 1 min et 11 s avec les scripts Ninja générés par Meson.

De son côté, GStreamer se configure en 14 secondes avec Autotools et 4,5 secondes avec Meson, puis se compile en 2 min et 36 s avec les Autotools et 1 min 57 s avec Meson.

Tierces notes
Notons que d’autres outils comme Bazel et Buck ont une approche différente pour optimiser les temps de compilation. Ces outils de construction utilisent en direct les compilateurs de différents langages de programmation sans passer par l’intermédiaire des outils de construction comme make ou ninja. Chaque approche à ses avantages et inconvénients. Ici, l’avantage de Meson, par rapport à Bazel et Buck, est de permettre au développeur ou à l’intégrateur d’avoir la main sur l’outil de construction (ninja, Visual C++ ou Xcode).

De son côté, GNOME Builder 3.28 prend en charge nativement les projets utilisant Meson, en plus de la prise en charge de CMake.

Le constructeur de distribution GNU/Linux Yocto le prend en charge directement dans sa base depuis la version 2.5-sumo.

Exemples de projets portés sur meson

Depuis 2016 environ, Meson est considéré comme assez mûr et a déclenché la migration de certains projets. Plus de 70 projets ont déjà basculé sur Meson. Parmi eux :

GStreamer (dès 2016) ;
GTK+ et GNOME (en 2017) ;
systemd ;
Wayland ;
Mesa 3D ;
libVA ;
fwupd ;
sysprof ;
X.Org ;
etc. (retrouvez ici la liste complète).

Conclusion

Meson est :

multi‐plate‐forme : GNU/Linux, macOS, Windows, GCC, Clang, Visual Studio ;
multi‐langage : Fortran, C, C++, Rust, Java, D ;
facile : configuration et définitions lisible et amicale ;
optimisé : pour faciliter les compilations complètes et incrémentales ;
moderne : gère les builds reproductibles ;
possède gestionnaire intégré de dépendances : fonctionne avec les paquets des distros ;
bien documenté ;
fun !

Si quelques choix peuvent paraître hasardeux, cela ne gêne personne, au regard de la liste des projets l’utilisant dès à présent, et par leurs tailles pour certains. Au final, Meson semble sur la bonne voie, sans être pour autant une révolution. Il s’agit davantage d’une évolution naturelle après quelques dizaines d’années de pratiques de la compilation de projets standards et multi-plates‐formes.

Aller plus loin

Meson (site officiel) (461 clics)
Ninja (site officiel) (200 clics)

# Yocto

Posté par David Marec le 08 octobre 2018 à 01:21. Évalué à 9.
Je ne sais plus ce que j'avais écrit lors de la rédaction, mais, pour être plus précis:
- Yocto (en fait poky) le prend en charge nativement depuis Sumo, c'est à dire sans passer pour les layers d'openembedded, (depuis les recettes devtools de la meta-oe de mémoire).
- et, je crois que c'est passé à la trappe, que CMake utilise par défaut Ninja depuis Sumo. On peut repasser aux Makefile, mais il faut le préciser désormais. -j'ai du le faire deux ou trois fois -
# Autres portages

Posté par Salamandar le 08 octobre 2018 à 08:10. Évalué à 10.

Pour info, j'ai porté Gimp (et ses outils babl et GEGL), je n'attends plus que le merge.

Pareil pour cinnamon et Nemo, la plus part des librairies sont désormais compilées avec Meson. Le choix a été fait de supprimer le support des Autotools.
- [^] # Re: Autres portages
  
  Posté par barmic le 08 octobre 2018 à 11:13. Évalué à 7.
  
  Et au final la migration s'est bien passé ? Il y a eu des adaptations à faire ? Ça t'a pris combien de temps ? Le gars est significatif ?
  - [^] # Re: Autres portages
    
    Posté par Salamandar le 17 octobre 2018 à 19:20. Évalué à 6.
    
    Oui ça s'est bien passé.
    il faut juste faire attention aux variables de chemins qui sont absolus sur autotools, et relatifs au prefix sous meson (donc utiliser join_paths).
    Et le truc relou est les variables de preproc qui sont créées automatiquement par autotools. Mais ça permet de voir réellement quelles variables sont utilisées par le code et de trouver d'éventuels bugs.
    
    En tout cas, c'est un bonheur de passer à un language propre.
- [^] # Re: Autres portages
  
  Posté par Maderios le 08 octobre 2018 à 12:44. Évalué à 8. Dernière modification le 08 octobre 2018 à 12:49.
  
  Du coté de Arch Aur, Enlightenment et Terminology sont compilés avec Meson. Pour les EFL, Meson est en voie d'être utilisé
  
  here comes meson
  a new shiny buildtool that currently completes in the total of ~ 4 min..
  1 min. conf time
  2:30 min. build time
  Where autotools takes:
  1:50 min. conf time
  3:40 min. build time.
# Try and fail

Posté par Firwen (site web personnel) le 08 octobre 2018 à 08:30. Évalué à 4.
J'ai donné une chance à Meson sur un de mes derniers projets et je dois dire qu'il avait des avantages pour lui :
- Syntaxe claire et explicite ( Pas de variable non existante qui sont mise à "null" à la CMake, ou de bordel sans nom mixant m4 et bash à la autotools )
- Excellente intégration avec pkg-config
- Rapide
- Bonne documentation.
Ceci dit, il a échoué très rapidement et je suis revenu à CMake quand j'ai réalisé qu'il supportait pas les RPATH à l'installation….
- [^] # Re: Try and fail
  
  Posté par Maz (site web personnel) le 08 octobre 2018 à 08:54. Évalué à 9.
  
  quand j'ai réalisé qu'il supportait pas les RPATH à l'installation….
  
  Pour les dilettantes comme moi, tu pourrais expliquer un peu ?
  
  Je suppose qu'il supporte pas de faire un « install » dans un répertoire précis, mais uniquement à la racine ?
  - [^] # Re: Try and fail
    
    Posté par Firwen (site web personnel) le 08 octobre 2018 à 15:04. Évalué à 7.
    
    Je suppose qu'il supporte pas de faire un « install » dans un répertoire précis, mais uniquement à la racine ?
    
    Non je parle de RPATH & DT_RUNPATH : https://en.wikipedia.org/wiki/Rpath
    
    RPATH t'autorise à encoder directement dans tes libraries le chemin d'accés à leur dépendance. Ce qui rend l'installation de tes logiciels dans un environment "prefixé" (cad en dehors de /usr/lib ) plus simple à utiliser.
- [^] # Re: Try and fail
  
  Posté par GaMa (site web personnel) le 08 octobre 2018 à 11:39. Évalué à 10.
  
  j'ai réalisé qu'il supportait pas les RPATH à l'installation…
  
  Tu veux parler de build_rpath et install_rpath de l'objet executable (https://mesonbuild.com/Reference-manual.html#executable) ?
  
  Matthieu Gautier|irc:starmad
  - [^] # Re: Try and fail
    
    Posté par Firwen (site web personnel) le 08 octobre 2018 à 15:02. Évalué à 10. Dernière modification le 08 octobre 2018 à 15:02.
    
    Tu veux parler de build_rpath et install_rpath de l'objet executable (https://mesonbuild.com/Reference-manual.html#executable) ?
    
    Exactement, Ils l'ont donc ajouté. Trés bonne nouvelle.
    
    Le RPATH à l'installation est souvent indispensable en environment HPC si on veut eviter d'avoir des LD_LIBRARY_PATH à 300 entrées…
# Un nouveau standard ?

Posté par martoni (site web personnel, Mastodon) le 08 octobre 2018 à 10:33. Évalué à 0.

Pourquoi est-que je ne peux pas m’empêcher de penser au strip de xkcd en lisant ça ?

J'ai plus qu'une balle
- [^] # Re: Un nouveau standard ?
  
  Posté par Fabrice Mousset (site web personnel) le 08 octobre 2018 à 10:44. Évalué à 6. Dernière modification le 08 octobre 2018 à 10:44.
  
  Hmmm, pas vraiment d'accord.
  
  Meson ne prétends pas être un nouveau standard mais réponds à un besoin qui est de rendre la compilation de gros projets plus rapide en évitant/supprimant les outils devenu trop lourds de part l'historique qu'ils sont obligés de traîner avec eux.
  
  Comme tout nouvel outil, il n'est pas parfait et ne répondra sans doute jamais à tous les besoins. Mais il a le mérite d'apporter une réponse à ce problème (tout comme CMake).
  
  Pour le commun des mortels, ce n'est qu'anecdotique, mais quand on travail sur un projet avec beaucoup de dépendances et options, gagner quelques minutes par compilation ce n'est pas négligeable quand on est obliger de faire plusieurs compilations par jour
  - [^] # Re: Un nouveau standard ?
    
    Posté par arnaudus le 08 octobre 2018 à 10:56. Évalué à 7.
    
    Je crois que je comprend un peu ce que veut dire l'OP. La réalité, c'est que la diversité dans les systèmes de build est incoutournable, et qu'il n'est pas réaliste de faire comme si elle n'existait pas. L'avantage avec les autotools, c'est que quand on téléchargeait un tar.gz, on savait qu'il fallait faire ./configure && make && sudo make install. Là, chaque système de build vient avec une syntaxe à lui. Bien sûr, la réponse évidente, c'est "il suffit de remplacer make par ninja, et truc par machin, et de rajouter l'option --bidule = target, rien de bien sorcier. Sauf que chaque système de build concurrent va venir avec sa syntaxe, et que connaitre les syntaxes des 12 systèmes de build courants, ça va être possible pour un admin sys, mais pas pour quelqu'un qui installe un truc hors paquet de sa distrib tous les six mois.
    
    Moi je trouve que les trois étapes "configuration", "compilation", "installation" sont très claires, et qu'il existait déja une syntaxe (pas forcément très logique, pas forcément intuitive, mais elle avait le mérite d'exister). Pourquoi ne pas s'être débrouillé pour que tout système de build génère par défaut un exécutable "configure" dans le répertoire, un Makefile minimal de trois lignes qui appelle ninja ou n'importe quoi d'autre, avec une cible "install" qui installe le truc? C'est ça le problème, c'est l'apparition de nouvelles syntaxes pour faire la même chose qu'avant.
    - [^] # Re: Un nouveau standard ?
      
      Posté par barmic le 08 octobre 2018 à 11:12. Évalué à 4. Dernière modification le 08 octobre 2018 à 11:12.
      
      Ça n'est pas un standard et ça n'a pas vocation à l'être. Des outils de builds il y en a déjà un tas, on a pas attendu meson pour que ce soit l'anarchie.
      
      Pourquoi ne pas s'être débrouillé pour que tout système de build génère par défaut un exécutable "configure" dans le répertoire, un Makefile minimal de trois lignes qui appelle ninja ou n'importe quoi d'autre, avec une cible "install" qui installe le truc? C'est ça le problème, c'est l'apparition de nouvelles syntaxes pour faire la même chose qu'avant.
      
      Parce que ça ne changerait rien au problème ? Ça te gêne d'avoir d'autres commandes que ./configure && make && make install, mais le fais qu'il soit nécessaire d'installer ninja avant ne te gène pas ? Ou que les outils comme checkinstall ne fonctionnent plus ?
      
      Tenter de ressembler, mais ne pas être compatible est bien pire que d'être plus ou moins compatible. Tout ça pour qu'au final la proportion de gars qui font des installations depuis les sources soit ridicules (d'autant qu'ils ont juste des commandes différentes à utiliser) face au temps passé par les dev et les intégrateurs à faire des builds un paquet de fois par jour (et leurs serveurs qui font ça en boucle).
    - [^] # Re: Un nouveau standard ?
      
      Posté par liberforce (site web personnel) le 08 octobre 2018 à 11:19. Évalué à 3. Dernière modification le 08 octobre 2018 à 11:19.
      
      un Makefile minimal de trois lignes qui appelle ninja
      
      Tu réalises que Ninja est un remplaçant à Make ? Si au lieu de remplacer une brique par une autre équivalente tu préfères rajouter un wrapper et une nouvelle dépendance, t'es pas sorti de l'auberge…
      - [^] # Re: Un nouveau standard ?
        
        Posté par arnaudus le 08 octobre 2018 à 11:40. Évalué à 3.
        
        Tu réalises que Ninja est un remplaçant à Make ?
        
        Non, ça n'est pas un remplaçant, et c'est bien ça le problème. systemd est un remplaçant à sysVinit, mais ninja est une alternative à make. Tu es donc exactement dans la situation décrite par le xkcd ; tu crées un système alternatif avec l'espoir qu'il remplace à terme l'existant, mais tu crées juste une nouvelle syntaxe qui s'additionne aux systèmes de build alternatifs qui existent.
        
        Si au lieu de remplacer une brique par une autre équivalente tu préfères rajouter un wrapper et une nouvelle dépendance, t'es pas sorti de l'auberge…
        
        Une dépendance à GNU make sur une distribution linux? C'est le genre de dépendance qu'on peut certainement assumer, non? En plus, la dépendance peut très facilement sauter si ton système de configuration fait en sorte de tester la présence de make sur le système.
        
        Je pense justement que le coût d'une dépendance à un logiciel qui est installé par défaut sur la quasi-totalité des distributions et un wrapper trivial est minime par rapport au coût d'être dans l'inconnu total quand tu télécharges un .tar.gz.
        
        [^] # Re: Un nouveau standard ?
        
        Posté par liberforce (site web personnel) le 08 octobre 2018 à 12:19. Évalué à 6.
        
        Non, ça n'est pas un remplaçant, et c'est bien ça le problème.
        
        J'ai dit "un remplaçant", pas "le remplaçant".
        
        systemd est un remplaçant à sysVinit, mais ninja est une alternative à make.
        
        Ah. Parce que systemd n'a pas commencé comme "un système alternatif avec l'espoir qu'il remplace à terme l'existant" ? Tu crois que les gars proclament "je suis le remplaçant de ", et les moutons suivent ? Ce qui différencie l'alternative du remplaçant, c'est juste le taux d'adoption, et ce taux varie en fonction du temps. Ou alors on m'aurait menti et Betamax est le remplaçant et VHS l'alternative ?
        
        Créer des alternatives, c'est ce qui fait émerger des remplaçants. Tu ne peux pas te plaindre que des gens essaient de faire mieux que l'existant, et n'y arrivent pas pour des raisons multiples. Sinon autant jeter tous les OS alternatifs, il y a Windows.
        
        Une dépendance à GNU make sur une distribution linux? C'est le genre de dépendance qu'on peut certainement assumer, non?
        
        Ces outils sont multi-plateforme et permettent la cross-compilation aussi, et l'utilisation en contexte embarqué… Ta distrib Linux sur ton PC x64 c'est carrément pas le débat.
        
        [^] # Re: Un nouveau standard ?
        
        Posté par Yth (Mastodon) le 08 octobre 2018 à 12:28. Évalué à 6.
        
        Une dépendance à GNU make sur une distribution linux? C'est le genre de dépendance qu'on peut certainement assumer, non?
        
        Une dépendance à init, ou alsa/oss, sur une distribution Linux ? C'est le genre de dépendance qu'on peut certainement présupposer, non ?
        
        Yth.
        
        PS : Sérieux, wrapper ninja dans make ?
        PPS : Mais qui compile sans lire les fichiers README et INSTALL, ne serait-ce que pour vérifier que ça marche avec ./configure && make && make install ? Et si le fichier INSTALL te dit « meson && ninja && ninja install » ça change quoi au fond ?
        PPPS : Et puis, qui utilise make install ailleurs que dans un script de création de paquet ? Ça arrive souvent aux gens de pourrir leur distrib et leur système de gestion de paquets en installant n'importe quoi à l'arrache comme ça ?
        
        [^] # Re: Un nouveau standard ?
        
        Posté par barmic le 08 octobre 2018 à 12:33. Évalué à 1.
        
        Tu es donc exactement dans la situation décrite par le xkcd ; tu crées un système alternatif avec l'espoir qu'il remplace à terme l'existant, mais tu crées juste une nouvelle syntaxe qui s'additionne aux systèmes de build alternatifs qui existent.
        
        Non tu crée un build plus rapide parce que ton build est lent. Je ne pense pas que meson ai vocation à gouverner le monde.
        
        Je pense justement que le coût d'une dépendance à un logiciel qui est installé par défaut sur la quasi-totalité des distributions et un wrapper trivial est minime par rapport au coût d'être dans l'inconnu total quand tu télécharges un .tar.gz.
        
        Tu aura toujours besoin de découvrir qu'il faut installer meson, python et ninja, hein ? Les 3 pauvres commandes ne changent pas grand chose au problème du « qu'est-ce que je fais quand je télécharge un .tar.gz ? »
    - [^] # Re: Un nouveau standard ?
      
      Posté par Selso (site web personnel) le 08 octobre 2018 à 11:41. Évalué à 2.
      
      Je n'ai pas de problème à l'utilisation des autotools,
      et je dirais même que l'utilisation des autres outils suit sensiblement les mêmes étapes.
      
      Le problème c'est de packager avec les autotools : il te faut maitriser plusieurs langages (M4, Make, bash, et je crois encore un autre…) dont certains ne vont servir qu'à ça.
    - [^] # Re: Un nouveau standard ?
      
      Posté par Fabrice Mousset (site web personnel) le 08 octobre 2018 à 12:17. Évalué à 1.
      
      Tu trouves "normal" d'utiliser ./configure && make && sudo make install pour installer un logiciel que tu compiles à partir de ces sources… mais avant de pouvoir faire cela, il t'a bien fallut installer un tas d'outils (en particulier les autotools, make, gcc, etc.)
      ET que le dit projet utilise les autotools.
      
      Pour compiler un projet qui utilise meson (ou CMake), et il te faudra installer meson (ou CMake) ainsi que ninja et python3.
      Et puis faire quelque chose dans le genre meson /sources /builddir && ninja -C /builddir -jxx && sudo ninja -C /builddir install
      
      Bref, pour l'utilisateur lambda, ce n'est pas franchement plus compliqué à mon sens.
      
      Le but, c'est de faire gagner du temps aux personnes qui sont obligées de faire plusieurs itérations (packaging, tests, etc.).
      Le but de Meson n'est pas forcément de faire autrement que autotools + make, mais de le faire le plus rapidement possible. Pour simplifier la vie des intégrateurs/testeurs/développeurs.
      - [^] # Re: Un nouveau standard ?
        
        Posté par Matthieu Moy (site web personnel) le 08 octobre 2018 à 16:00. Évalué à 5. Dernière modification le 08 octobre 2018 à 16:00.
        
        il t'a bien fallut installer un tas d'outils (en particulier les autotools
        
        Non justement, le principe des autotools c'est qu'ils sont installés sur la machine du développeur, mais on n'en a pas besoin pour installer.
        
        [^] # Re: Un nouveau standard ?
        
        Posté par Fabrice Mousset (site web personnel) le 08 octobre 2018 à 16:37. Évalué à -2.
        
        Si on compile à partir des sources (ce qui est le cas ici) avec ./configure && make && make install, les autotools doivent être installés sur la machine…
        sinon ./configure ne fonctionnera pas!
        
        Où alors j'ai rien compris :(
        
        [^] # Re: Un nouveau standard ?
        
        Posté par Matthieu Moy (site web personnel) le 09 octobre 2018 à 09:08. Évalué à 8.
        
        Où alors j'ai rien compris :(
        
        Bah ….
        
        Le ./configure est un fichier généré par les autotools, tu n'as pas besoin du générateur (donc des autotools) pour le lancer.
        
        C'est un choix discutable, mais c'est ce choix qui est à la fois une force d'autotools (besoin de très peu de chose sur la machine où on compile) et à l'origine de la plupart des ennuis des autotools : toute la chaîne de génération est coupée en deux, une partie « développeur » et une partie « utilisateur qui compile à partir des sources ». Avec automake par exemple, as un Makefile généré à partir d'un Makefile.in par un script généré par le configure, qui est généré à partir du configure.ac par autoconf. Le Makefile.in est généré à partir du Makefile.am par automake. Simple, hein ? ;-)
        
        [^] # Re: Un nouveau standard ?
        
        Posté par benoar le 09 octobre 2018 à 13:55. Évalué à 5.
        
        les autotools doivent être installés sur la machine…
        sinon ./configure ne fonctionnera pas!
        
        Où alors j'ai rien compris :(
        
        Tu n'as effectivement pas compris. Les prérequis d'un configure sont très simples : un shell et les outils Unix de base. C'est d'ailleurs la raison de sa « lourdeur » : il fait tout avec ces prérequis très minimaux, ce qui est assez contraignant, et oblige à plein de contournements lourds en ressources.
        
        De même, tu n'auras pas besoin des autotools tant que tu ne fais pas de modification du système de build lui-même : tu peux modifier les fichiers source et recompiler sans avoir les autotools. Un ajout de fichier ou de dépendance de bibliothèque, par contre, t'obligera à les avoir, et faire un coup d'autoreconf.
        
        [^] # Re: Un nouveau standard ?
        
        Posté par barmic le 09 octobre 2018 à 14:42. Évalué à -2.
        
        Les prérequis d'un configure sont très simples : un shell et les outils Unix de base.
        
        make ? le compilateur ? la bibliothèque standard du C ou C++ ? Ce n'est pas dans les outils de base de ma distribution.
        
        [^] # Re: Un nouveau standard ?
        
        Posté par Yth (Mastodon) le 09 octobre 2018 à 14:56. Évalué à 7.
        
        D'un autre côté tu es dans un processus de compilation de logiciel.
        Si t'as pas de compilateur, t'as un problème, mais il n'est absolument pas lié aux autotools…
        
        Yth.
        
        [^] # Re: Un nouveau standard ?
        
        Posté par benoar le 09 octobre 2018 à 15:07. Évalué à 6.
        
        make ? le compilateur ? la bibliothèque standard du C ou C++ ? Ce n'est pas dans les outils de base de ma distribution.
        
        Ça l'était à une époque. Et ma remarque était pour dire qu'en gros, si tu veux compiler un outil depuis les sources, bien sûr qu'il faut un compilateur, mais tu n'auras pas besoin de télécharger le dernier outil de build à la mode : tout ce qui est hors des outils que tu cites et qui sont historiquement considérés comme « standards » est superflu.
        
        Bref, point de vue utilisateur du logiciel (depuis les sources, donc utilisateur avancé quand même), pas besoin même de « système de build » puisque du point de vue de celui qui exécute ./configure, autotools n'est pas nécessaire.
        
        Comme dit Matthieu, le cas « utilisateur qui compile et modifie éventuellement » peut paraître étrange par rapport au dev qui veut modifier la procédure de build et plus, mais c'est une dichotomie qui valait à une certaine époque et que je trouve toujours bonne pour un paquet de projets aujourd'hui. La preuve par cette news elle-même : c'est encore un nouveau standard nécessaire pour compiler X projets. Autotools ne sera jamais nécessaire pour un développeur qui fait des modifications minimes.
        
        [^] # Re: Un nouveau standard ?
        
        Posté par barmic le 09 octobre 2018 à 16:14. Évalué à 3.
        
        Bref, point de vue utilisateur du logiciel (depuis les sources, donc utilisateur avancé quand même), pas besoin même de « système de build » puisque du point de vue de celui qui exécute ./configure, autotools n'est pas nécessaire.
        
        En fait on s'en fout pas mal de son point de vu. Ce que vous voulais c'est un système de packaging de sources standard hors ça n'existe pas parce qu'il y a pleins de projets qui ont déjà un système différents. On parle de C et C++, mais si tu joue avec des programmes en python, en java, en go, en rust, en js,… tu aura des dizaines de builder et c'est normale. Le build est un outil du développeur. Lui il l'exécute plusieurs dizaines de fois par jours. La minute qu'il perd à cause de sont build peut facilement représenter des dizaines de minutes dans la journée, ralentir son intégration continue ça ralenti tous sont travaille, ne pas pouvoir lancer un build + les tests tout le temps ça nuit à la qualité de ce qu'il te fourni.
        
        À coté de ça changer les habitudes de quelques utilisateurs qui ne veulent pas lire un fichier INSTALL et qui ne veulent pas changer leur 3 commandes (alors qu'ils vont bien devoir installe meson, python et ninja !). Ça ne représente pas un intérêt énorme.
        
        Les packageurs de distribution sont déjà habitués à gérer un paquet de builder différents (tu as même Debian (et d'autres je présume) qui fait des builds via différent compilateurs).
        
        Le builder est un outil du développeurs, pas un système de packaging.
        
        [^] # Re: Un nouveau standard ?
        
        Posté par freem le 10 octobre 2018 à 09:02. Évalué à 3.
        
        Le builder est un outil du développeurs, pas un système de packaging.
        
        Ah? Et pourquoi ça?
        
        La compilation et la création de paquets c'est quand même vachement proche:
        
        quand je compile, je prend des sources pour générer un ou plusieurs binaires et j'établis d'éventuelles relations entre eux;
        
        quand je fais un paquet, je prend des sources pour générer… ah, ben, la même chose en fait?
        
        Si on part de Make, dans son usage traditionnel avec le C ou le C++, son backend est un compilateur et un éditeur de liens, mais qu'est-ce qui empêcherait d'avoir dpkg-deb à la place?
        Au final, pourquoi a création d'un paquet, ça ne serait pas juste une cible de compilation, de la même manière qu'on peut ne recompiler qu'un seul des éléments d'un projet?
        D'ailleurs, CMake justement permets de générer des paquets Debian ainsi que des installateurs windows si ma mémoire ne me trompe pas. Et je ne serais pas surpris que ça puisse générer des rpm.
        
        [^] # Re: Un nouveau standard ?
        
        Posté par barmic le 10 octobre 2018 à 09:15. Évalué à 1.
        
        Ah? Et pourquoi ça?
        
        Par système de packaging, j'entendais gestionnaire de paquets (désolé c'était pas clair). Ce que nous disent benoar et d'autres c'est qu'ils aiment les autotools en tant que gestionnaire de paquet (en lieu et place de dpkg, rpm ou flatpack). Je veux signifier que c'est un usage totalement à la marge et que les gains apportés pour les usages conventionnels sont bien plus grands que l'inconvénient qu'ils voient sur l'usage qu'ils en font.
        
        Bien sûr que ton build peut générer des artifacts qui sont des packages que ce soit pour des linuxeries (deb/rpm/flatpack) voir pour des trucs comme des images docker ou autre.
        
        [^] # Re: Un nouveau standard ?
        
        Posté par benoar le 11 octobre 2018 à 14:47. Évalué à 5.
        
        Ce que nous disent benoar et d'autres c'est qu'ils aiment les autotools en tant que gestionnaire de paquet (en lieu et place de dpkg, rpm ou flatpack). Je veux signifier que c'est un usage totalement à la marge et que les gains apportés pour les usages conventionnels sont bien plus grands que l'inconvénient qu'ils voient sur l'usage qu'ils en font.
        
        Je ne suis pas d'accord que ça soit un usage « totalement à la marge » : le projet GNU a établit des standards https://www.gnu.org/prep/standards/standards.html qui, lorsqu'ils sont suivis (en utilisant les autotools) permettent de correctement distribuer un travail (on parle de « distribution » dans la terminologie autotools pour désigner un tarball d'une version donnée d'un logiciel). Ça n'est pas non plus un gestionnaire de paquet complet : c'est un entre deux, mais c'est bien plus que simplement un système de build. Je l'avais décrit comme permettant de faire bien plus que juste compiler dans une présentation que j'avais faite http://dolka.fr/bazar/atelier_empaquetage_facon_GNU/atelier_empaquetage_facon_GNU.pres.html : ça permet de distribuer, d'informer de la licence, de faciliter la reproductibilité et la disponibilité des sources. Des choses qui sont plutôt l'apanage des système de gestion de paquet d'habitude (comme celui de Debian, qui couvre tous ces aspects également).
        
        Voir également https://www.gnu.org/software/automake/manual/automake.html#Introducing-the-GNU-Build-System
        
        L'inconvénient que tu citais plus haut sur les perfs, je ne comprends pas : le configure n'est fait qu'une fois, après tu "make" quand tu changes un fichier et c'est très rapide.
        
        Bien sûr, comme tout système qui se veut être le seul standard, d'autres sont venus le contredire, et les « distributions » au sens classique du terme (ensemble de logiciels intégrés avec un noyau) sont venu « uniformiser » ça ; bien sûr, on a eu plusieurs distributions…
        
        Et dire que c'est juste « changer les habitudes » de quelques utilisateurs, oui, si tu veux… mais alors pourquoi a-t-on inventé les distributions pour englober / uniformiser ça ? Parce les utilisateurs ne veulent pas juste s'emmerder.
        
        [^] # Re: Un nouveau standard ?
        
        Posté par Renault (site web personnel) le 11 octobre 2018 à 14:58. Évalué à 6.
        
        L'inconvénient que tu citais plus haut sur les perfs, je ne comprends pas : le configure n'est fait qu'une fois, après tu "make" quand tu changes un fichier et c'est très rapide.
        
        Il n'y a pas que le cas où tu développes une application seule que le temps du configure entre en jeux.
        
        Exemple, dans l'embarqué on génère très souvent des images entiers à base de buildroot et Yocto. Pour faire les choses bien on a une intégration continue sur le système avec nos changements. Résultat l'image doit être régénérée à chaque fois de 0 (cela signifie refaire le configure de centaines / milliers de paquets à chaque nouveau commit ou nouvelle livraison).
        
        Une fois on a monitoré le temps passé à construire une image. Sur l'heure nécessaire à générer une image fraiche, environ un tiers était passé dans les différents configure. Soit environ 20 minutes. C'est quand même assez long.
        
        Et dire que c'est juste « changer les habitudes » de quelques utilisateurs, oui, si tu veux… mais alors pourquoi a-t-on inventé les distributions pour englober / uniformiser ça ? Parce les utilisateurs ne veulent pas juste s'emmerder.
        
        Une distribution c'est un peu plus qu'un simple gestionnaire de paquets. Nombre d'entre elles d'ailleurs s'échangent les outils volontiers.
        
        [^] # Re: Un nouveau standard ?
        
        Posté par benoar le 15 octobre 2018 à 09:51. Évalué à 3.
        
        Exemple, dans l'embarqué on génère très souvent des images entiers à base de buildroot et Yocto. Pour faire les choses bien on a une intégration continue sur le système avec nos changements. Résultat l'image doit être régénérée à chaque fois de 0 (cela signifie refaire le configure de centaines / milliers de paquets à chaque nouveau commit ou nouvelle livraison).
        
        C'est marrant que tu me parles de Yocto, je me le tape tous les jours et je peux te le dire : Yocto n'a pas du tout la bonne approche. Rebuilder depuis les sources à chaque fois, sans reproductibilité binaire, ça n'est pas la bonne manière de faire. C'est même idiot. Voir comment font les distros classique pour comprendre pourquoi.
        
        C'est comme ce que j'ai dit au-dessus à propos de ne pas avoir à relancer le configure à chaque make : ça serait débile.
        
        [^] # Re: Un nouveau standard ?
        
        Posté par freem le 17 octobre 2018 à 09:37. Évalué à 3.
        
        Voir comment font les distros classique pour comprendre pourquoi.
        
        Un lien ou une explication rapide seraient appréciés.
        
        [^] # Re: Un nouveau standard ?
        
        Posté par benoar le 19 octobre 2018 à 10:38. Évalué à 2.
        
        https://wiki.debian.org/ReproducibleBuilds
        
        Les distros depuient toujours buildent des paquets binaires et assembles ces paquets dans une « distribution ». L'assemblage est fait bien après la compilation, et ce depuis toujours, avant même que les build reproductibles existent.
        
        Yocto, par design d'ailleurs — il se dit un « créateur de distribution —, a un système qui veut essayer de tracker tout changement en re-faisant un build total au moindre changement de variable où que ce soit dans le projet. Du coup tout change tout le temps, point de vue binaire. L'intention peut paraître bonne, mais le résultat est pour moi catastrophique : plutôt que d'essayer de régler les problèmes de dépendances cachées (chose qu'on essaye de détecter par les builds reproductibles, entre autre), ils essayent de compartimenter un maximum les logiciels, avec les problèmes de practicité que ça amène, jusqu'à l'absurde : il faut reproduire aujourd'hui dans le système de Yocto l'équivalent de ce que fait déjà autotools ou les autres systèmes de build (détection de dépendance, chemins, etc). Introduire une modification dans ce système sans tout casser est quasi-impossible, du coup ici les gens préfèrent surtout ne rien toucher, ou alors font des gros hacks dégueux : bravo le résultat.
        
        Bon, après, récemment ils ont l'air de changer un peu point de vue reproductibilité binaire : https://reproducible-builds.org/blog/posts/181/ (mais pas côté compartimentation débile).
        
        [^] # Re: Un nouveau standard ?
        
        Posté par freem le 19 octobre 2018 à 17:41. Évalué à 3. Dernière modification le 19 octobre 2018 à 17:42.
        
        Les builds reproductibles, ça me semble super, mais justement, même Debian (qui semble être plus ou moins à l'origine du mouvement, du moins c'est l'impression que j'ai eue la première fois ou j'en ai entendu parler) n'y parviens pas.
        
        Et de ce que j'ai cru comprendre en survolant le sujet (de haut le survol, hein… ça m'intéresse, mais je n'ai pas eu le temps de creuser vraiment… mais cette piqûre va me faire re-survoler tout ça au minimum) j'ai cru comprendre que le but c'est justement de pouvoir avoir le même binaire en compilant avec les mêmes sources et la même configuration depuis un environnement différent, histoire de garantir que l'environnement n'introduit pas de problèmes, justement.
        
        Du coup, je ne vois pas le rapport entre les build reproductibles et Yocto qui rebuild au moindre changement de source?
        
        [^] # Re: Un nouveau standard ?
        
        Posté par benoar le 23 octobre 2018 à 11:16. Évalué à 4.
        
        Debian n'y arrive pas à 100%, mais a de bon résultats quand même :
        https://tests.reproducible-builds.org/debian/reproducible.html
        Et Tails atteint même (je ne sais pas si c'est toujours le cas) la reproductibilité d'une ISO !
        https://tails.boum.org/contribute/build/reproducible/
        
        Et effectivement, une fois que tous les problèmes de reproductibilité seront corrigés (doux rêve), on pourra dire que re-builder depuis les sources est sans conséquence particulière pour le déterminisme du comportement du logiciel résultant. Mais garantir la reproductibilité dans le temps avec le flot de modifications qui arrive tout le temps, c'est difficile, et je pense qu'il y aura toujours quelques différences pour une plage étendue de logiciels.
        
        Le rapport avec Yocto, c'est sur les changements de l'environnement de build justement, pas des sources : Yocto rebuild au moindre changement d'environnement d'un soft tout l'OS, ce qui donne des résultats binaires différents à chaque fois car ils ne se concentrent pas sur la reproductibilité. Leur ligne directrice est que les sources sont la racine de « raison », et qu'on doit pouvoir obtenir en gros la même chose, du moment qu'on track la moindre modification de l'environnement de build. Ça marche à peu près bien niveau résultat au sens du comportement du soft résultant, mais niveau reproductibilité des binaires c'est zéro. Et l'ironie, c'est qu'ils se basent sur la disponibilité des sources en lignes, en trackant par défaut les derniers git : niveau reproductibilité, faire comme ça en général c'est garanti que ça ne marche pas (les dépôts bougent, etc).
        
        [^] # Re: Un nouveau standard ?
        
        Posté par Renault (site web personnel) le 23 octobre 2018 à 11:50. Évalué à 3.
        
        Et effectivement, une fois que tous les problèmes de reproductibilité seront corrigés (doux rêve), on pourra dire que re-builder depuis les sources est sans conséquence particulière pour le déterminisme du comportement du logiciel résultant.
        
        Beaucoup de soucis de reproductibilité sont liés à des variables insérées dans le binaire lors de la compilation mais qui sont sans incidence fonctionnelle sur le résultat. Par exemple la date de la compilation, le nom de la machine qui a compilé, etc.
        
        Ce n'est pas pour rien que Debian soit en avance sur le sujet par rapport à d'autres. Debian a une architecture de compilation qui repose sur les machines de ses empaqueteurs contrairement à d'autres où c'est centralisé sur les serveurs du projet comme Fedora. Le but de la reproductibilité est que quiconque puisse vérifier que le binaire obtenu depuis les dépôts correspond bien aux sources du projet et suivant les instructions de l'empaqueteur.
        
        Car il est bien plus aisé pour un être malveillant de faire un acte nuisible dans le cas de Debian que dans le cas où c'est plus centralisé. Et probablement plus discret aussi. Car la sécurité de ces machines est moins contrôlée.
        
        Le rapport avec Yocto, c'est sur les changements de l'environnement de build justement, pas des sources : Yocto rebuild au moindre changement d'environnement d'un soft tout l'OS, ce qui donne des résultats binaires différents à chaque fois car ils ne se concentrent pas sur la reproductibilité.
        
        Je ne comprends pas ce que tu veux dire.
        Si tu changes la recette pour obtenir le GCC pour la compilation croisée, comme le GCC résultant va changer, il faut en effet tout refaire.
        
        Mais si tu ne changes rien, Yocto va tout garder en place. Au boulot ce n'est pas vraiment un soucis à l'usage. Uniquement lors des MaJ de Yocto (changement de GCC, Glibc, noyau, etc.) cela nécessite une reprise de zéro.
        
        Et si tu mets à jour ta Fedora qui a un nouveau GCC par exemple, rien à refaire non plus.
        
        c'est qu'ils se basent sur la disponibilité des sources en lignes, en trackant par défaut les derniers git : niveau reproductibilité, faire comme ça en général c'est garanti que ça ne marche pas (les dépôts bougent, etc).
        
        Bof non, en général le numéro de commit de référence est renseigné. Justement pour limiter le soucis que tu pointes.
        
        [^] # Re: Un nouveau standard ?
        
        Posté par freem le 23 octobre 2018 à 11:58. Évalué à 2. Dernière modification le 23 octobre 2018 à 12:00.
        
        Debian […] a de bon résultats quand même
        
        Je n'ai jamais dit le contraire, je mettais juste l'accent sur le fait que si c'est déjà difficile pour l'une des distributions qui dispose du plus de contributions (opinions purement et simplement tirée d'une perception erronée de la réalité) alors ça ne risque pas d'être trivial.
        
        une fois que tous les problèmes de reproductibilité seront corrigés (doux rêve)
        
        Ironiquement, et dans le sujet du journal, ça implique de se passer de cmake, puisque ce dernier inclue le chemin absolu vers le fichier source quand on utilise la macro __FILE__, ce qui est extrêmement désagréable (compiler manuellement avec des chemins relatifs résous le problème avec gcc et clang, donc c'est bien la faute de l'outil qui génère le process de build.
        De la même manière, la moindre modif de l'endroit où l'on compile implique de devoir reconfigurer… c'est hyper chiant!
        Je constate d'ailleurs que j'ai oublié de poser la question, je vais corriger ça de suite. Peut-être que la réponse me plaira.
        Et si ce problème est solvable en passant à meson, je pense que je vais au moins switcher mes projets persos dans un 1er temps, puis voire pour le pousser au taf (là ou avoir la possibilité de debug sans devoir squatter le PC ou compiler depuis un chroot (mes collègues ont déjà du mal à faire des commits propres, je vais pas leur imposer ça) serait vraiment une valeur ajoutée…).
        
        Mais garantir la reproductibilité dans le temps avec le flot de modifications qui arrive tout le temps, c'est difficile
        
        Si le source brut change, c'est même impossible. Ce que j'entend par source brut, c'est le source après passage du pré-compilateur, sans les caractères blancs ni les commentaires.
        
        Le rapport avec Yocto, c'est sur les changements de l'environnement de build justement, pas des sources : Yocto rebuild au moindre changement d'environnement d'un soft tout l'OS, ce qui donne des résultats binaires différents à chaque fois car ils ne se concentrent pas sur la reproductibilité.
        
        S'ils se basaient sur des programmes «réputés reproductibles», et s'ils ne s'amusent pas à inclure les données d'environnement ( HOME, $(date), horodatage des fichiers source, ce genre de choses) ça ne devrait pas être insurmontable, tu as bien montré que certains arrivent à avoir une ISO qui est reproductible.
        
        Et l'ironie, c'est qu'ils se basent sur la disponibilité des sources en lignes, en trackant par défaut les derniers git
        
        C'est dommage pour la repro, mais c'est pertinent pour les bugfixes. De ce que tu m'expliques, j'ai l'impression de parler d'une Arch pour l'embarqué en fait. Je suppose que c'est un choix…
        
        [^] # Re: Un nouveau standard ?
        
        Posté par barmic le 11 octobre 2018 à 16:55. Évalué à 4.
        
        Je ne suis pas d'accord que ça soit un usage « totalement à la marge » : le projet GNU a établit des standards https://www.gnu.org/prep/standards/standards.html qui, lorsqu'ils sont suivis (en utilisant les autotools) permettent de correctement distribuer un travail (on parle de « distribution » dans la terminologie autotools pour désigner un tarball d'une version donnée d'un logiciel).
        
        Je sais pas comment le dire autrement. Ça fait déjà un paquet de fois que je le dis, mais bon…
        
        Tu ne pourra jamais respecter ce standard sans utiliser les autotools. Jamais. Tu peux tenter d'y ressembler, mais ton configure ne ferra pas la même chose, ton make sera différent et ton make install.
        
        L'intérêt de ce standard ce n'est pas d'avoir un script configure et d'utiliser make, mais de décrire ce que font chacune de ses étapes et comment elles le font. Hors quand tu utilise meson ils ne feront pas la même chose ou de la même façon. C'est ce qui permet à d'autres outils de s'interfacer avec (pense à checkinstall). Produire un simulacre d'autotools s'apparenterait plus à du « Embrace, extend and extinguish » qu'autre chose.
        
        Du coup :
        
        Et dire que c'est juste « changer les habitudes » de quelques utilisateurs, oui, si tu veux… mais alors pourquoi a-t-on inventé les distributions pour englober / uniformiser ça ? Parce les utilisateurs ne veulent pas juste s'emmerder.
        
        Oui le fait d'avoir les même commandes exactement ce n'est qu'une question d'habitude et pas de standard. Si vous êtes satisfait avec les commandes c'est que le standard ne vous intéresse pas tant que ça et que c'est plus une question d'habitude des commandes.
        
        Une solution pourrait être que meson génère un dist un tar.gz qui ne dépend que des autotools, mais ça signifie qu'il produit une seconde chaîne de build et s'assurer que les 2 sont bien équivalentes est très compliqué.
        
        [^] # Re: Un nouveau standard ?
        
        Posté par arnaudus le 10 octobre 2018 à 10:23. Évalué à 5.
        
        Le builder est un outil du développeurs, pas un système de packaging.
        
        Si c'était vrai, tu te distribuerais pas le système de build avec tes sources (tu ne distribues pas les options de ton IDE, ni ton compilateur…). Le fait d'avoir une cible "install" montre bien que tu distribues un pseudo-paquet.
      - [^] # Re: Un nouveau standard ?
        
        Posté par arnaudus le 08 octobre 2018 à 16:09. Évalué à 2.
        
        Bref, pour l'utilisateur lambda, ce n'est pas franchement plus compliqué à mon sens.
        
        Ce qui est compliqué, c'est d'avoir une procédure différente pour chaque machin que tu veux compiler, en fonction des préférences du développeur. Ton raisonnement pourrait être poussé à l'extrême; si le dev a mis au point son propre système de build et qu'il te faut taper "gogo-gadget o compilateur", tu vas trouver ça débile, même si c'est marqué dans le README.
        
        Ça n'est pas non plus pour rien qu'il y a des standards de facto, et je trouve que la compilation se prêterait justement pas mal à avoir une procédure un peu normalisée (avec un certain nombre de cibles standard: clean, make, install, etc). J'imagine aussi que ça simplifierait pas mal la vie aux différentes distributions, et que ça réduirait la fragmentation.
        
        [^] # Re: Un nouveau standard ?
        
        Posté par Fabrice Mousset (site web personnel) le 08 octobre 2018 à 16:47. Évalué à 3. Dernière modification le 08 octobre 2018 à 16:47.
        
        On est d'accord ;)
        
        Mais ça c'est la liberté de chacun de choisir l'environnement et les outils de développement qui lui conviennent le mieux.
        Mais ça c'est un autre débat!
        
        Si meson ou CMake s'imposent tout doucement comme outils de développement pour les projets d'envergures, c'est parce qu'ils répondent à un besoin de performance de compilation.
        Et si cela se poursuit, l'utilisation des autotools ne sera plus qu'un lointain souvenir… tout comme CVS et d'autres outils de dev.
        
        [^] # Re: Un nouveau standard ?
        
        Posté par freem le 08 octobre 2018 à 17:19. Évalué à 3.
        
        un lointain souvenir… tout comme CVS et d'autres outils de dev.
        
        Hum… un lointain souvenir CSV, vraiment?
        
        [^] # Re: Un nouveau standard ?
        
        Posté par ʭ ☯ le 09 octobre 2018 à 11:09. Évalué à 5.
        
        Oui. Ce n'est pas parce qu'un logiciel existe encore qu'il reste dominant. Aujourd'hui, un étudiant en informatique va apprendre directement avec git, pas svn ou cvs. Et quand il arrivera chez OpenBSD, il migrera leur suivi de sources ;-) Ah oui, il y a une autre option, ils refusent, et le projet meurt lentement…
        
        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
        
        [^] # Re: Un nouveau standard ?
        
        Posté par arnaudus le 08 octobre 2018 à 17:34. Évalué à 2.
        
        Si meson ou CMake s'imposent tout doucement comme outils de développement pour les projets d'envergures
        
        L'intention n'était évidemment pas d'empêcher les gens d'utiliser un système de build différent de GNU make et autotools. Je trouve juste que ces systèmes alternatifs auraient pu faire l'effort de fournir une interface à peu près normalisée afin qu'il soit trivial de passer de l'un à l'autre, voire de complètement abstraire la procédure de compilation derrière une interface unique.
        
        [^] # Re: Un nouveau standard ?
        
        Posté par liberforce (site web personnel) le 09 octobre 2018 à 10:17. Évalué à 2.
        
        Quand tu as déjà n projets existants qui font les choses différemment, c'est quoi la norme ? Quand tu as ./configure && make && make install et que tu ne veux pas utiliser make mais ninja, tu as déjà 50% de la commande qui change. Si tu veux abstraire l'appel à make ou équivalent, tu te retrouves à faire comme CMake: cmake --build va appeler make ou ninja selon le type de générateur configuré au départ. Sauf qu'alors tu dévies encore plus de ton ./configure && make && make install initial. Bref, il n'y a pas trop le choix.
        
        [^] # Re: Un nouveau standard ?
        
        Posté par claudex le 09 octobre 2018 à 11:30. Évalué à 4. Dernière modification le 09 octobre 2018 à 11:30.
        
        Sans compter les projets qui ont leur propre wrapper shell autour d'autre outils et il faut appeler "build.sh" ou équivalent.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
    - [^] # Re: Un nouveau standard ?
      
      Posté par bubar🦥 (Mastodon) le 09 octobre 2018 à 19:07. Évalué à 4. Dernière modification le 09 octobre 2018 à 19:07.
      
      Dans la vie réelle il y a toujours ./configure --help ET la lecture du script, car c'est très courant que le configure ne te donne que QQ options, voir parfois aucune à part les siennes, donc IRL on lit
      Non ?
# on en a déjà parlé dans la meson.

Posté par Selso (site web personnel) le 08 octobre 2018 à 11:44. Évalué à 2.

Concernant le tour des solutions existantes, Meson a déjà été cité par ici

Et le problème c'était que ça ne marchait pas ! L'article étant de 06/2018, écrit par apparemment un habitué des builds multi-plateformes je me pose quelques questions, bien que vous listiez en fin un liste de success stories.
- [^] # Re: on en a déjà parlé dans la meson.
  
  Posté par liberforce (site web personnel) le 08 octobre 2018 à 12:31. Évalué à 5.
  
  Tu m'excuseras, mais l'auteur de article en question dit seulement:
  
  Bon là je désespère. Encore un outil qui veut être le plus rapide et toujours pas d'outil qui prétend fonctionner correctement.
  
  Je n'ai jamais utilisé Meson mais on m'a dit que c'est-nouveau-c'est-bien-tu-devrais-essayer.
  
  Pourquoi pas, enfin moi je cherche surtout un truc qui me génère de quoi faire un build iOS, Android, OSX et Linux. Un truc qui juste marche quoi.
  
  On est loin du propos argumenté là… La définition de "ça marche" est différente pour chacun, parce que ça dépend des besoins de chacun. Qu'est-ce qui n'a pas marché pour lui ?
  - [^] # Re: on en a déjà parlé dans la meson.
    
    Posté par barmic le 08 octobre 2018 à 12:34. Évalué à 1.
    
    Surtout que du coup la cross compilation est détaillée.
  - [^] # Re: on en a déjà parlé dans la meson.
    
    Posté par Selso (site web personnel) le 08 octobre 2018 à 17:08. Évalué à 1. Dernière modification le 08 octobre 2018 à 17:08.
    
    Bon c'est exact, il n'a pas dit exactement que ça ne marchait pas, mais simplement que le projet n'était pas dans le but d'offrir quelque chose de plus stable, mais de plus rapide. Donc il a supposé que Meson n'a pas été écrit dans le but de corriger les problèmes constatés par ailleurs et que cela ne valait pas la peine de l'essayer.
    - [^] # Re: on en a déjà parlé dans la meson.
      
      Posté par Julien Jorge (site web personnel) le 08 octobre 2018 à 21:28. Évalué à 7.
      
      Alors, comme je suis l'auteur du journal cité je peux préciser :)
      
      Je n'ai jamais utilisé Meson et par conséquent je n'ai pas d'avis sur la façon dont l'outil est développé ni sur son approche de la gestion du build.
      
      Je suis néanmoins déçu de voir que la caractéristique mise en avant est « ça va vite » parce que le temps de configuration et de compilation sont loin d'être les premiers de mes soucis. Pour les tailles de projets sur lesquels je travaille il n'y a pas de problème de temps de configuration avec CMake et pour la compilation de ces projets ninja ne fait pas mieux qu'un make -j$(nproc). Mon principal problème est surtout d'avoir des builds simples à gérer pour quatre plates-formes. Moins j'ai de spécificités à gérer, mieux je me porte.
      
      Chromium est souvent pris en exemple pour appuyer le fait que Ninja (principal backend de Meson) est bien plus rapide que Make mais il ne faut pas oublier que c'est un projet de plusieurs dizaines de millions de lignes de code. C'est loin d'être un projet de taille moyenne.
      
      Quelque part je me dis que le temps passé à développer Meson aurait été mieux investi à améliorer CMake (qui peut aussi générer des scripts Ninja), mais bon la concurrence a aussi du bon. Quand je vois les progrès de Firefox depuis l'arrivée de Chrome je me dit que ça peut avoir de bons côtés.
      - [^] # Re: on en a déjà parlé dans la meson.
        
        Posté par liberforce (site web personnel) le 09 octobre 2018 à 09:31. Évalué à 3.
        
        Pour les tailles de projets sur lesquels je travaille il n'y a pas de problème de temps de configuration avec CMake
        
        Perso, j'avais fait quelques tests sous Windows + MSYS2 pour des applis GTK+ à peine plus compliquées qu'un hello world. C'était sur un Asus Transformer T100, donc pas une bête de course: Intel Atom et eMMC pour le stockage. Bin j'avais déjà un gros écart à la configuration entre CMake et Meson (de l'ordre de la centaine de ms avec Meson, et de l'ordre de la seconde avec CMake). Donc pas besoin de milliers de lignes de code pour voir un bénéfice.
# Remplçant make distcheck

Posté par saltimbanque (site web personnel) le 08 octobre 2018 à 13:06. Évalué à 3. Dernière modification le 08 octobre 2018 à 13:06.

GNOME utilisait cette cible pour produire les release. En cherchant je pourrai retrouver quel nouveau mode op' ils ont adopté, mais vous saurez peut être plus largement ce que différents projets anciens utilisateurs de distcheck ont fait?

# hello world

Posté par goeb le 08 octobre 2018 à 13:34. Évalué à 5.

Pour illustrer le principe, existe-t-il un exemple minimal de Meson, ce qu'on appelle généralement un "hello world" ?

[^] # Re: hello world

Posté par liberforce (site web personnel) le 08 octobre 2018 à 14:45. Évalué à 10. Dernière modification le 08 octobre 2018 à 14:45.

Pour un hello world en C:

project('tutorial', 'c')
executable('demo', 'main.c')

Pour un projet C en GTK+:

project('tutorial', 'c')
gtkdep = dependency('gtk+-3.0')
executable('demo', 'main.c', dependencies : gtkdep)

Source: http://mesonbuild.com/Tutorial.html