E.T. téléphone Meson

Posté par  . Édité par Julien Jorge, Davy Defaud, bubar🦥, Benoît Sibaud, ZeroHeure et Bruno Michel. Modéré par Pierre Jarillon. Licence CC By‑SA.
Étiquettes :
75
7
oct.
2018
C et C++

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

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 :

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

  • # Yocto

    Posté par  (site web personnel) . É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  . É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  . É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  . É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  . É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.

      Poster une information ne signifie pas nécessairement adhésion

  • # Try and fail

    Posté par  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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

  • # Un nouveau standard ?

    Posté par  (site web personnel, Mastodon) . Évalué à 0.

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

    Titre de l'image

    J'ai plus qu'une balle

    • [^] # Re: Un nouveau standard ?

      Posté par  (site web personnel) . É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  . É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  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  (Mastodon) . É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  . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  . É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  . É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  (Mastodon) . É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  . É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  . É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  . É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  . É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  . É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  (site web personnel) . É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  . É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  . É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  . É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  . É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  . É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  (site web personnel) . É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  . É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  . É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  . É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  . É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  (site web personnel) . É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  . É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  . É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  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  . É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  (site web personnel) . É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

      • [^] # Re: hello world

        Posté par  (site web personnel) . Évalué à 3.

        Je dis ça, je dis rien:

        PROG= coucou                                                                                              
        NO_OBJ= yes
        SRCS=  main.c
        MK_MAN= no
        .include <bsd.progs.mk>
        PROG= wincoucou                                                                                              
        NO_OBJ=
        SRCS=  test.c
        MK_MAN= no
        GTK_I= `pkgconf --cflags gtk+-2.0`
        GTK_L= `pkgconf --libs gtk+-2.0`
        CFLAGS+= ${GTK_I}
        LDADD+= ${GTK_L}
        .include <bsd.progs.mk>
  • # Quelques questions...

    Posté par  . Évalué à 7. Dernière modification le 08 octobre 2018 à 15:14.

    Perso, quand j'essaies d'utiliser CMake (et j'y arrive, tant bien que mal, l'air de rien), je crois que les 2 trucs qui me cassent le plus les pieds c'est:

    • l'intégration du (D)VCS. Il y a quantité de littérature sur comment extraire le dernier tag+le dernier hash court et l'intégrer dans le CMake, mais jusqu'ici, je n'ai rien trouvé de vraiment clair. En l'occurrence, je parle de git, le plus utilisé du moment selon mon pifomètre, mais je ne doute pas que le problème se retrouve avec les autres. Si je dois migrer à un nouveau BS (Build System, pas Bull Shit… quoique…) il va au moins falloir que ça, ce soit simple.
    • le triste "la compilation (ou est-ce le linkage? Je sais jamais) à échoué, vous pouvez avoir plus d'informations en passant -v". Sous-entendu: passer -v au compilo, pas à make, bien sûr. Bref, comment que ça se passe avec Meson?

    Autre point qui m'a fait tiquer dans la dépêche:

    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 scrolls trop longs et de se concentrer sur le dernier élément. En outre, le compteur d'étape est agréable pour savoir où on en est dans la compilation (particulièrement pour les très gros projets aux longues compilations).

    Euh, vous êtes sérieux la? Non, parce que si j'oublie un ";" après la "}" d'une classe ou structure en C++, l'erreur ne sera pas immédiate, mais arrivera bien après. Donc, c'est la 1ère erreur qui est importante, pas la dernière.
    Ce n'est qu'un seul exemple, mais bien souvent dans mon cas les erreurs de compilations se corrigent en cascade, et pas comme un saumon qui remonte sa rivière…

    Pour le reste, c'est à voir, si en effet il gère aisément les dépendances externes, ça peut être sympa, parce qu'avec CMake, quand on inclue une dépendance, on sait jamais si c'est LIBRARY, LIBRARIES, le nom n'est jamais trop sûr non plus et aller lire les fichiers qui l'indiquent (qui sont multiples) est bien lourd.
    Sauf que, en fait, à bien y réfléchir, ça se fait pas trop mal avec cmake, si on utilise pkg-config, et non leur système intégré (parce que de toute façon, je me suis aperçu avec le temps que je finis toujours par utiliser des libs qui n'exposent pas de fichier cmake au système, alors que les fichiers pour pkg-config c'est la norme sous *nux).
    Bon, je reconnaît que l'inconvénient du coup, c'est Windows. Pas comme si Windows n'avait jamais été une plaie dans la gestion des dépendances de build, non plus.
    Conclusion pour ce paragraphe: et chez vous, pour exporter une lib, ça marche comment?

    Pour ce qui est de ninja, j'ai lu dans le manuel de cmake une rumeur comme quoi il serait aussi supporté. Du coup, vu que la vitesse de meson semble l'argument de «vente» le plus mis en avant, et qu'il est avoué que c'est dû au fait d'utiliser uniquement ninja, ça donne quoi, une comparaison de vitesse à la loyale?
    Parce qu'à moi, le fait de supporter un maximum de backend me semble une force, pas une faiblesse. J'avais lu il y a quelques années (dans le contexte de pondre une API de plugins) un papier des gens de chez google qui argumentaient sur le fait que, pour avoir une API à peu près stable et robuste, il fallait au moins 3 outils qui l'implémentent, et que plus il y en a, mieux c'est. Je n'arrive pas à le retrouver, mais ma mémoire m'indique que l'argumentaire était plutôt robuste et convainquant.

    • [^] # Re: Quelques questions...

      Posté par  (site web personnel) . Évalué à 3. Dernière modification le 09 octobre 2018 à 09:55.

      Pour ce qui est de ninja, j'ai lu dans le manuel de cmake une rumeur comme quoi il serait aussi supporté

      C'est plus qu'une rumeur, CMake gère de manière expérimentale Ninja depuis au moins CMake 3.0, et n'est plus marqué comme expérimental dans la documentation depuis CMake 3.3 (juillet 2015).

      le fait de supporter un maximum de backend me semble une force, pas une faiblesse.

      Mais ça augmente la complexité, et tu dois ensuite abstraire ce que peut faire un système et pas l'autre. C'est l'éternel débat entre s'adapter au plus petit dénominateur commun vs exploiter les capacités au maximum en utilisant les spécificités.

  • # et qmake et qbs ?

    Posté par  . Évalué à 2.

    Bonjour,
    il me semble que Qt a prévu de faire une transition vers un autre système qbs qui viendrait remplacer qmake.
    Comme il s'agit d'un système qui semble être similaire, quelqu'un a t il resté cela ?
    Je trouvais que le format des fichiers .pro avec qmake était assez clair.
    Certes cela génère un makefile derrière, donc on ne gagne pas de temps (qbs je n'ai pas regardé).
    Bonne fin de journée

    • [^] # Re: et qmake et qbs ?

      Posté par  (site web personnel) . Évalué à 8.

      Ceci est mon retour d'utilisateur de qmake en tant que développeur de logiciel propriétaire pour le milieu de la micro-électronique (ne me jetez pas la pierre, il faut bien payer son loyer…).
      qmake marche bien pour gérer des projets C++/Qt «classique». Mais dès que tu veux faire des trucs «un peu exotique», c'est une vraie plaie dans le c**. Il faut se montrer très «créatif» dans les .pro et utiliser des fonctionnalités non documentées dont tu découvres l’existence dans le wiki de Qt ou sur des forums.
      Un exemple concret. Notre logiciel utilise un framework tierce (FlexNet) pour gérer les licences et s'assurer que le client utilise notre outil dans les conditions prévus par le contrat qu'il a signé (notamment nombre d'instances du logiciel pouvant s'exécuter en parallèles et fonctionnalités du logiciel. Ce framework nous est fourni sous la forme d'une archive à décompresser, et exécuter un simple make dedans pour générer la bibliothèque à intégrer dans notre outil. Vu que nos clients utilisent diverses architectures et plateformes (essentiellement RHEL 5/6/7 en amd64, mais pas que), nous avons décidés (à tort ?) d'intégrer ce framework dans notre projet .pro sous forme de sous-projet source pourqu'il soit compilé automatiquement par notre système d'intégration continue pour les plateformes cibles. Et là, c'est le drame parce qu'il n'y a pas de moyen simple d'expliquer à qmake que ce sous-projet se compile avec un simple make et qu'il peut utiliser le résultat pour le linker à notre soft. Et on ne peut pas non plus créer un .pro spécifique à ce projet (du moins facilement, j'ai essayé plus d'une fois), parce que le make sus-nommé fait de la «magie» : il génère un exécutable qui va générer les .h/.so que l'on va utiliser (l'éditeur du framework a choisi la sécurité par l'obscurité. L’exécutable va générer une version obfusqué de toute leur tambouille interne, qui va être appelé par l'API à laquelle on a accès). Du coup, on a dû définir une cible virtuelle qui appel un script bash qui compile le framework. Yeah…
      Autre exemple, notre appli utilise le thème QtCurve qui est géré par CMake. Et là aussi, qmake ne gère pas cmake et on a du faire preuve de «créativité» pour que cela s'intègre à notre solution.
      Donc voila, mon point est que qmake manque cruellement de flexibilité. Alors certes, certains pourraient nous reprocher de l’utiliser dans des cadres non prévus pour. Et j'ai presque envie d'être d'accord avec eux. Mais je considère qu'un moteur de production doit s'adapter à l'utilisateur et non l'inverse.

      Concernant QBS, je ne l'ai utilisé que dans des projets persos. Pour l'instant, le seul truc que j'ai à lui reprocher est qu'il ne gère pas pas les «promogate» utilisé dans Qt Designer. Il n'arrive pas à trouver les .h de mes widgets custom. Ça se résous en ajoutant manuellement le dossier du projet courant et tant que dossier d'include. Pour moi, c'est une regression vue que qmake gérait ça nativement. Problème trouvé en convertissant un vieux projet .pro vers .qbs. Et manifestement, c'est un vieux problème.

  • # Options

    Posté par  . Évalué à 2.

    Merci pour cet article très intéressant, même si je ne suis pas développeur, il m'arrive assez régulièrement de compiler des logiciels.

    Là où les autotools faisai en t : (petite erreur d'accord)
    /chemin/vers/sources/configure --prefix=/mon/prefix --enable-some-option
    … Meson fait :
    meson /chemin/vers/sources/ --prefix=/mon/prefix -Dsome-option=true

    Pour avoir la liste des options disponibles avec les autotools, je fais un configure --help.
    Y a-t-il un équivalent avec meson ?

    • [^] # Re: Options

      Posté par  . Évalué à 2.

      Pour avoir la liste des options disponibles avec les autotools, je fais un configure --help.
      Y a-t-il un équivalent avec meson ?

      Oui, 'meson configure'.

      • [^] # Re: Options

        Posté par  (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 08 octobre 2018 à 19:47.

        Cependant y a une petite incohérence ici, car ça ne fonctionne pour voir la liste des options qu'une fois le projet configuré avec succès une fois. Ce qui est ironique quand parfois on doit pouvoir configurer les options pour justement permettre le succès de la configuration!

        On est donc forcé de se coltiner le fichier meson_options.txt avec son éditeur pour lister les options. Il existe une demande de fonctionnalité pour permettre d'obtenir la liste des options depuis un appel de commande (issue 2402). C'est un petit recul (même si la lecture d'un fichier bien tenu rend la chose moins terrible).

        L'interface ncurses à la ccmake serait aussi une bonne alternative (dans les projets CMake, je ne configure quasi que comme cela) mais c'est aussi en demande de fonctionnalité (comme indiqué dans la dépêche).

        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

        • [^] # Re: Options

          Posté par  . Évalué à 2.

          Ok, merci pour la réponse.

    • [^] # Re: Options

      Posté par  (site web personnel) . Évalué à 3.

      Là où les autotools faisai en t : (petite erreur d'accord)

      Corrigé, merci.

  • # Je n'aime pas

    Posté par  (site web personnel) . Évalué à 3.

    J'ai suivi meson dès les premiers jours de sa conception, à la création du canal IRC jusqu'à aujourd'hui. Je n'aime pas ce build system.

    • Comme souvent dit, c'est un nouveau build system, il y en a déjà trop (CMake, Scons, autotools, waf, gyp, premake). Ajouter un nouveau complexifie encore plus la construction des paquets. Avoir un nouveau système dit support des IDEs à attendre. Il a fallu attendre un moment avant d'avoir une intégrité complète de CMake dans Qt Creator, KDevelop, NetBeans et VS. Cela ne pourrait qu'empirer avec un nouveau système.
    • Meson importe lui même les modules du monde entier (dans sa façon de voir les choses). C'est pour ça que vous avez un module Qt, GNOME, RPM, … à mon sens ce n'est pas au build système de s'intégrer avec tous les frameworks de la terre entière. Par exemple, il n'y a pas ce problème avec pkg-config, ce sont bien les développeur qui installent eux même leur .pc (ou au pire la distribution). C'est vrai que CMake a aussi encore plein de modules maison, mais la recommendation actuelle est de fournir un fichier d'export dans la bibliothèque, de la même manière que les .pc.
    • CMake est très clairement le build system le plus avancé en matière de C et C++. Je l'utilise depuis 10 ans maintenant. J'ai des choses à lui reprocher mais pas tant que ça et lorsque je trouve des choses à améliorer j'envoie des correctifs.

    Ceci dit, je trouve qu'un beau Makefile peut aussi parfois suffire lorsque le logiciel en question est largement portable. Je regrette juste qu'il n'y ai pas une syntaxe de Makefile puissante et standardisée.

    git is great because linus did it, mercurial is better because he didn't

    • [^] # Re: Je n'aime pas

      Posté par  (site web personnel) . Évalué à 3. Dernière modification le 09 octobre 2018 à 10:37.

      c'est un nouveau build system, il y en a déjà trop

      Comme je l'ai dit plus haut, c'est un faux problème. Personne n'arrive à faire les choses parfaitement du premier coup. Il faut des essais, et des échecs (les siens ou ceux des autres), pour en tirer des leçons et faire mieux la fois suivante. Je suis d'accord avec toi pour la gestion par les IDE, mais là c'est le problème des IDE. Pas besoin d'un IDE pour tirer profit d'un outil de build. C'est une solution de confort, et si une solution prend l'ascendant, elle sera gérée, comme cela a été le cas pour CMake.

      Meson importe lui même les modules du monde entier (dans sa façon de voir les choses). C'est pour ça que vous avez un module Qt, GNOME, RPM, … à mon sens ce n'est pas au build système de s'intégrer avec tous les frameworks de la terre entière.

      Sauf quand les projets ont des besoins particuliers. On ne peut pas demander à chaque application de redévelopper tout ce qui était déjà fait et le réinclure. Il faut un endroit centralisé pour cela. Meson montre que comme autotools avec ses macros, il est capable de gérer les spécificités des projets. Dans le cas de GNOME, ça va être de compiler des schémas, des fichiers de ressources, de la documentation, des fichiers d'introspection. Compiler et générer, c'est le job du build system, alors pourquoi pas le centraliser là bas ? C'est un atout pour les projets souhaitant migrer.

      CMake est très clairement le build system le plus avancé en matière de C et C++. Je l'utilise depuis 10 ans maintenant.

      https://yourbias.is/the-sunk-cost-fallacy

      J'ai des choses à lui reprocher mais pas tant que ça et lorsque je trouve des choses à améliorer j'envoie des correctifs.

      Et c'est bien de contribuer. Mais de même qu'il y a de la place pour plus qu'un seul OS, je pense qu'il y a de place pour plus d'un build system.

      • [^] # Re: Je n'aime pas

        Posté par  (site web personnel) . Évalué à 3.

        Comme je l'ai dit plus haut, c'est un faux problème. Personne n'arrive à faire les choses parfaitement du premier coup. Il faut des essais, et des échecs (les siens ou ceux des autres), pour en tirer des leçons et faire mieux la fois suivante

        La solution parfaite n'existe pas. Meson aura des défauts et parmi ceux là j'insiste sur le fait qu'il ne devrait pas avoir à gérer les frameworks lui même.

        Sauf quand les projets ont des besoins particuliers. On ne peut pas demander à chaque application de redévelopper tout ce qui était déjà fait et le réinclure. Il faut un endroit centralisé pour cela. Meson montre que comme autotools avec ses macros, il est capable de gérer les spécificités des projets. Dans le cas de GNOME, ça va être de compiler des schémas, des fichiers de ressources, de la documentation, des fichiers d'introspection. Compiler et générer, c'est le job du build system, alors pourquoi pas le centraliser là bas ? C'est un atout pour les projets souhaitant migrer.

        Justement CMake possède un système de fonctions puissant, c'est pour ça que Qt5 permet de fournir par Qt directement, un ensemble de macros nécessaire pour créer des projets Qt comme : les traductions et les .ui. Ceci est fourni avec Qt, il serait tout à fait possible de le faire avec n'importe quel autre framework sans même que CMake ait une quelconque information.

        git is great because linus did it, mercurial is better because he didn't

      • [^] # Re: Je n'aime pas

        Posté par  . Évalué à 4. Dernière modification le 09 octobre 2018 à 19:50.

        Meson importe lui même les modules du monde entier (dans sa façon de voir les choses). C'est pour ça que vous avez un module Qt, GNOME, RPM, … à mon sens ce n'est pas au build système de s'intégrer avec tous les frameworks de la terre entière.

        Sauf quand les projets ont des besoins particuliers. On ne peut pas demander à chaque application de redévelopper tout ce qui était déjà fait et le réinclure. Il faut un endroit centralisé pour cela. Meson montre que comme autotools avec ses macros, il est capable de gérer les spécificités des projets. Dans le cas de GNOME, ça va être de compiler des schémas, des fichiers de ressources, de la documentation, des fichiers d'introspection. Compiler et générer, c'est le job du build system, alors pourquoi pas le centraliser là bas ? C'est un atout pour les projets souhaitant migrer.

        J'ajouterais ici que le problème si il y en a un, est du coté des frameworks qui font leurs choix, imposent leurs outils (qmake -> incontournable pour inspecter un kit Qt), la solution de CMake n'est pas nécessairement très différente. De plus, la philosophie de Meson est de factoriser au maximum ces cas particuliers pour éviter une des dérives avec CMake qui est que chaque projet ship plus de LOC CMake que de code C/C++… avec des tonnes de modules CMake pour faire des choses assez banales. C'est une des justifications aussi du choix de ne pas faire un langage "Turing complete", ça empêche la prolifération de modules custom.

        Si je prends encore l'exemple du module Qt, le code source est vraiment petit voir ici. Même si il n'est pas complet il me permet de compiler des applications avec Qt sans problème sur mac,linux,windows et cross win-linux.

        Si on regarde ici meson Vs Cmake j'ai quand même l'impression que ça respecte les promesses, c'est quand même bien plus lisible non?

        • [^] # Re: Je n'aime pas

          Posté par  . Évalué à 5.

          Si on regarde ici meson Vs Cmake j'ai quand même l'impression que ça respecte les promesses, c'est quand même bien plus lisible non?

          À ce que je vois:

          • la version de CMake effectue une analyse statique du code, pas celle de Meson;
          • la version de CMake ne sépare pas les heaers et les divers éléments de source, mais ce n'est pas à cause de CMake;
          • la version de Meson gère plus proprement les dépendances avec fallback, vrai que ça peut servir;
          • la version de CMake utilise GLOB_RECURSE, mais n'utilise pas les masques (qui, je sais, sont considérés comme une mauvaise pratique), du coup, pourquoi utiliser GLOB_RECURSE?
          • la version de CMake inclue du code zombie;
          • la version de CMake semble mentionner la possibilité de faire de l'édition de lien statique, pas celle de Meson;

          Conclusion:
          Oui, c'est vrai, la version de Meson semble plus lisible, mais elle semble faire moins de choses, d'une part, et ne pas avoir vieilli. Je suis quasiment sûr à la lecture des deux que la version Meson est une réécriture en se basant sur celle de CMake, et que du coup il n'y à pas les antécédents. Forcément, ça aide à faire plus lisible, mais c'est une comparaison injuste.
          Si demain un projet qui utilise Meson depuis plusieurs versions décide d'implémenter le support de CMake, les chances ne sont pas minces pour que le même phénomène se produise, pour moi: c'est facile de faire plus propre quand on à un exemple qui fonctionne (c'est une des raisons pour lesquelles je commence par écrire des PoC de mes codes avant de les reprendre. Le code qui en résulte n'est pas forcément propre, mais il n'est pas dégueulasse comme l'est souvent celui du PoC).

  • # Foutue hérédité

    Posté par  . Évalué à 10.

    « 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. »

    Ah… je comprends mieux !

  • # Question oubliée, sur le thème de la reproductibilité des builds

    Posté par  . Évalué à 5. Dernière modification le 23 octobre 2018 à 12:02.

    Dans CMake, utiliser la macro __FILE__ cause l'inclusion du nom de fichier absolu, ce qui est très pénible et lié au fait que cmake génère une configuration avec des noms de fichiers absolus et non relatifs à la racine du projet.

    Comment Meson se comporte-t-il sur ce point?

    PS: je le mets ici afin que l'auteur du journal soit notifié, au cas ou il ne suive pas le thread sur la repro.

  • # Python....

    Posté par  (site web personnel) . Évalué à 2.

    C'est dommage de l'avoir codé en Python pour le coup, et cela fait une dépendance, pas petite en plus.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.