Journal Un petit tour des systèmes de build

Posté par Julien Jorge (site web personnel) le 14 juin 2018 à 23:31. Licence CC By‑SA.

Étiquettes :

juin

2018

Sommaire

Quelques systèmes de build
- Make
- Autotools
- SCons
- Premake
- CMake
- Ninja
- Meson
- FASTbuild
- Sharpmake
- Maven
- Ant
- Gradle
Que choisir

Parlons un peu de systèmes de build.

Mon métier consiste à programmer des jeux vidéos destinés aux plates-formes mobiles Android et iOS. Ce qui est commun aux deux plates-formes, c’est-à-dire la plus grosse partie de l'application, est écrit en C++, et ce qui est spécifique à la plate-forme est en Java ou en Objective-C. L'intérêt principal de tout faire en C++ est que les développeurs peuvent lancer l'application directement sur leur poste de travail, sous Linux ou OSX, et tester leurs modifs sans payer le prix d'un émulateur ou du transfert sur un appareil mobile.

L'inconvénient est que l'on se retrouve à gérer des builds sur quatre plates-formes.

Pour compiler une application pour iOS il faut nécessairement un projet Xcode, bien que les bibliothèques puissent être compilées classiquement en ligne de commande. Cela signifie qu'il faut maintenir un fichier de projet Xcode ou alors avoir un outil pour le générer.

Côté Android la compilation du code C++ se fait avec l'outil ndk-build, qui est en réalité une interface à GNU Make. Du coup les fichiers de projet sont évidemment des makefiles mais utilisant des variables et fonctions d'une sorte de framework dans le langage de Make. Là encore il faut maintenir des makefiles pour le projet, ou avoir un outil pour les générer.

Pour Linux et OSX la compilation peut se faire avec des outils plus classiques mais évidemment pas avec les fichiers de build iOS ou Android. Et encore une fois il faut maintenir ces fichiers de build.

À moins qu'on ait un outil pour les générer tous…

Quelques systèmes de build

Le problème de la gestion de la compilation d'un projet a été posé bien avant ta naissance ; c'est pour cela qu'il n'existe qu'une seule méthode pour le faire, qui fait consensus depuis des décennies.

Ha ! Ha ! Ha !

Je peux te citer déjà douze outils de tête. Voyons un peu la présentation faite sur leurs sites respectifs et essayons de rester de bonne foi.

Make

D'après le site :

GNU Make est un outil qui contrôle la génération d'exécutables et autres fichiers non-source d'un programme à partir des fichiers source du programme.

J'ai mis la description du site de GNU Make mais la première version de Make date d'avril 1976. Elle précède ainsi le projet GNU de sept ans.

Le principe de base de Make est assez simple, on lui passe un fichier Makefile qui indique « voilà le fichier que je veux créer, il dépend de ces autres fichiers, et voilà les commandes à exécuter pour le créer ». Avec le mécanisme des dépendances l'outil se débrouille pour créer les cibles dans l'ordre.

Il m'arrive encore de créer des petits Makefiles manuellement mais c'est vite pénible. Par exemple, si un binaire app est créé à partir d'un fichier a.cpp qui inclut un fichier b.hpp qui inclut lui-même un fichier c.hpp, en toute rigueur je dois lister ces trois fichiers en dépendances de la cible app pour que la compilation soit refaite quand l'un d'eux est modifié. On fait ça une fois puis on cherche un truc pour que les dépendances soient gérées automatiquement.

Un autre point difficile à gérer concerne la dépendance au fichier Makefile lui-même. Par exemple, si j'ajoute une option qui concerne l'édition des liens, celle-ci ne sera pas refaite par défaut.

Autotools

[Le premier objectif des Autotools] est de simplifier le développement de programmes portables. Le système permet au développeur de se concentrer sur l'écriture du programme, simplifiant de nombreux détails de portabilité entre systèmes Unix et même Windows, et permettant au développeur de décrire comment construire le programme via des règles simples plutôt que des Makefiles complexes.

Si vous avez déjà utilisé les autotools vous êtes probablement morts de rire en lisant ce paragraphe. Cette suite d'outils qui se présente comme simple et portable est en réalité ce qu'il y a de plus complexe en système de build et n'est portable que sur les systèmes Unix en évitant soigneusement Windows, le plus déployé des systèmes des trente dernières années.

Sans doute révolutionnaire à sa création, cet outil a extrêmement mal vieillit. Pour ma part j'ai eu l'occasion de compiler des logiciels tiers sous Windows avec ça et c'était tout simplement l'enfer. J'ai aussi tenté de l'utiliser pour mes propres projets et je me suis arrêté dans le tuto. Depuis je suis convaincu que ces outils sont faits pour les développeurs qui aiment transpirer.

SCons

SCons est un outil Open Source de construction de logiciel—plus précisément, une nouvelle génération d'outil de construction. Voyez SCons comme un substitut amélioré et multi-plateforme pour l'utilitaire Make classique avec des fonctionnalités intégrées similaires à autoconf/automake et aux caches de compilation tels que ccache. Pour faire court, SCons est un moyen plus facile, plus fiable et plus rapide de construire un logiciel.

Wow, là c'est carrément le futur.

Les fichiers SCons s'écrivent directement en Python, ce qui est assez sympa puisqu'on se retrouve avec un vrai langage et un a accès à un tas de bibliothèques pour décrire le projet.

J'ai compilé quelques projets en SCons il y a une quinzaine d'années et je crois que je n'ai jamais rien vu d'aussi lent. Et pas seulement parce que c'est du Python…

Il faut dire que le comportement par défaut de l'outil est de détecter les modifications des fichiers sources en calculant un md5 des fichiers, pour éviter de recompiler des fichiers dont seule la date a changé. Quand on voit le prix d'un md5 je trouve ce choix très discutable. Ce comportement peut être modifié via une option mais même en passant sur une comparaison de timestamps et en appliquant toutes les astuces connues pour le rendre plus rapide, ça reste hyper lent.

Premake

Un système de configuration de construction puissamment simple
Décrivez votre logiciel qu'une seule fois, via la syntaxe simple et facile à lire de Premake, et construisez-le partout.
Générez des fichiers de projets pour Visual Studio, GNU Make, Xcode, Code::Blocks, et plus sous Windows, Mac OS X et Linux. Utilisez l'intégralité du moteur de script Lua pour que la configuration de la construction devienne du gâteau.

Pfiou, ça claque ! Ce n'est que le quatrième dans la liste et ça promet déjà de tout résoudre

Avec Premake les scripts de builds sont écrits en Lua et, à l'instar de SCons, cela permet de « programmer » son build en profitant de tout un tas de bibliothèques.

Sur le papier c'est très sympa, en pratique ça ne marche pas trop comme attendu. Il s'avère que la syntaxe de Premake est déclarative et ne se mélange pas bien avec le procédural de Lua. Par exemple, si j'écris

project "P"

if false then
    files
    {
      "file.cpp"
    }
end

On pourrait croire que le fichier file.cpp ne fera pas partie du projet P, et bien pas du tout, le if ne change rien du tout ici. Difficile de programmer dans ces conditions.

Nous utilisons Premake depuis presque quatre ans au boulot. Le choix s'est fait en sa faveur bien que l'outil était en alpha car il permettait de générer des fichiers pour Xcode et ndk-build via deux plugins indépendants, en plus des Makefiles classiques. Aussi, il avait l'air facile à hacker ce qui était rassurant.

Maintenant j'essaye de le remplacer autant que possible.

Parmi les problèmes récurrents le plus pénible est certainement le message error: (null), sans autre info, que l'outil affiche parce qu'une erreur s'est glissée dans un script. Bonne chance pour déboguer ça. J'aime aussi beaucoup le message Type 'premake5 --help' for help qui s'affiche quand je fais une faute de frappe sur la ligne de commande. Là encore il n'y a aucune information utile et il faut se débrouiller pour trouver où on s'est trompé. Autre souci : il n'y a pas moyen de mettre des propriétés de link spécifiques à une bibliothèque. C'est embêtant quand on a besoin d'un -Wl,--whole-archive.

Le développement de Premake en lui-même a l'air très laborieux. Quatre ans après il est toujours en alpha, avec une release datant d'août 2017. Le module Xcode a été intégré mais ne gère que OSX. Il a fallu réappliquer toutes nos modifs pour iOS. Quant au module pour le NDK il ne fonctionne plus suite à des changements dans Premake (hey, c'est une alpha…). Là encore il a fallu repatcher.

Il y a de nombreux contributeurs, dont des gros, mais chacun a l'air d'aller dans sa propre direction sans qu'il y ait d'objectif commun. Il y a par exemple deux générateurs de Makefiles, gmake et gmake2 (j'attends impatiemment yagmake). Il y a des fonctionnalités qui ne marchent qu'avec Visual Studio, d'autres trucs qui fonctionnaient il y a quatre ans et qui ne fonctionnent plus. Ça m'a l'air d'être typiquement le projet qui veut tout faire parfaitement et qui au final ne fait rien de bien. Bref, le produit n'est pas à la hauteur du pitch.

CMake

CMake est une suite d'outils open source et multi-plateforme conçus pour construire, tester et empaqueter des logiciels. CMake est utilisé pour contrôler le processus de compilation du logiciel via des fichiers de configuration indépendants du compilateur et de la plate-forme, et il génère des fichiers Makefiles natifs ou des projets qui peuvent être utilisé avec l'environnement de compilation de votre choix.

CMake est tout simplement mon outil de build préféré de ces quinze dernières années.

Tout est dit.

Bon OK, j'explique. CMake lit des fichiers CMakeLists.txt qui décrivent les projets à compiler dans un langage qui lui est propre. À partir de cela il génère des fichiers Makefile ou autres (des projets Xcode ou Visual Studio par exemple) qui permettent de construire le projet.

Ce qui m'a convaincu dans cet outil est qu'il est plutôt rapide (bien qu'il ne soit pas le plus rapide) et qu'il gère parfaitement les règles de reconstruction des cibles. Par exemple, si j'ajoute un paramètre de ligne de commande pour l'édition des liens, alors l'édition des liens va être refaite. Si je modifie un fichier CMakeLists.txt et que j'exécute make sans relancer CMake, alors CMake se relance tout seul (les Makefiles ont une règle de dépendance vers les CMakeLists.txt, pas con!) Je peux aussi simplement définir les répertoires d'entêtes, options de compilation et autres paramètres spécifiques à chaque projet, en précisant s'il le paramètre doit être visible des projets dépendants ou non.

L'outil est assez bien fichu et est très populaire dans le milieu du C++.

Un des points les plus souvent reprochés à CMake est son langage, notamment à l'époque de la version 2 de l'outil qui était excessivement verbeuse et en plus en ALL CAPS. On avait l'impression de se faire crier dessus à longueur de fichier. Aujourd'hui ces soucis sont résolus et le problème semble surtout être que cela fait un langage de plus à apprendre et qui ne sert à rien d'autre (contrairement à SCons et Premake par exemple). Perso je n'y vois pas de difficulté, c'est un bête langage à macros avec des mécanismes bien pratique pour nommer des groupes de paramètres.

Comme d'habitude la qualification « indépendants du compilateur et de la plate-forme » des fichiers de configuration est très discutable dans la mesure où il y a tout ce qu'il faut pour glisser des commandes système dans le build.

Les principaux problèmes que j'ai pu rencontrer avec une version récente de CMake concernent l'export de projet. En effet il y a une commande install(EXPORTS) qui permet de créer un fichier de configuration CMake pour inclure la cible en tant que dépendance dans un projet tiers. Malheureusement cette commande exporte par défaut les chemins absolus des dépendances de la cible et il faut bricoler pour exporter les dépendances proprement (en les enrobant dans des cibles importées par exemple).

Un autre souci est que CMake génère plein de fichiers intermédiaires et qu'avec la pratique généralisée de lancer le build à la racine du projet on se retrouve à polluer toute l'arborescence. Idéalement il faudrait que l'outil refuse de faire un build in-source.

Ninja

Ninja est un petit système de construction se concentrant sur la vitesse. Il est différent des autres systèmes de construction sur deux aspects majeurs : il est conçu pour que ses fichiers d'entrées soient générés par un système de construction de plus haut niveau, et il est aussi conçu pour exécuter les builds le plus rapidement possible.

Ah cool, encore un outil qui se veut rapide, c'est exactement ce qu'il nous manquait. En plus quand on voit SCons et Premake qui se prétendent déjà les plus rapides, on a tout de suite confiance. Cela dit, contrairement à SCons et Premake, Ninja n'est pas un générateur de script de build. Il serait plutôt à comparer à Make.

Je n'ai jamais utilisé Ninja mais si jamais mes builds devenaient très lents je n'hésiterais pas à y jeter un coup d'œil. À moins que je ne passe à Meson.

Meson

Meson est un système open source de construction voulant être à la fois extrêmement rapide et, encore plus important, aussi accessible que possible.

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.

FASTbuild

FASTBuild est un système de construction open source et de haute performance supportant une haute montée en charge de la compilation, la mise en cache et la distribution sur le réseau.

Non mais franchement…

Là encore je n'ai pas utilisé cet outil. La promesse est sympa mais je ne vois pas trop l'intérêt par rapport aux deux mille autres outils du même genre.

Sharpmake

Sharpmake est un générateur de projets et solutions pour Visual Studio. Il est similaire à CMake et Premake, mais il est conçu pour être rapide et passer à l'échelle.

Celui-ci est développé par Ubisoft initialement en interne et libéré en septembre 2017. Apparemment il n'y a plus d'activité dans le dépôt depuis octobre de la même année. Comme son nom l'indique, les scripts de build sont écrits en C#.

D'après la doc il sait aussi générer des projets pour Xcode et des Makefiles. J'ai longtemps considéré l'utiliser en remplaçant de Premake mais d'une part c'est écrit en C#, donc c'est mort pour l'utiliser sous Linux, et d'autre part je sens bien que tout ce qui n'est pas Windows et Visual Studio va être bancal.

Maven

Apache Maven un outil de compréhension et de gestion de projet logiciel. Basé sur le concept de modèle d'objet de projet, Maven peut gérer la construction, le compte-rendu et la documentation d'un projet depuis un élément central d'information.

Je ne sais pas vous mais moi je comprends à peine le descriptif. C'est peut-être ma traduction qui est foireuse.

Maven est un outil du monde Java. J'ai pu l'utiliser un peu via des scripts déjà prêts et il n'y a pas grand-chose à lui reprocher de ce point de vue. Ça m'a l'air assez cool pour la gestion des dépendances.

C'est un outil qui a l'air très professionnel. Ah mais attend… c'est pour ça qu'on comprend rien au descriptif ! La première version date de 2004 et c'est donc tout naturellement que le langage le plus populaire du début du siècle a été choisi pour les scripts de build, je parle bien sûr du 🎉 XML 🎉.

Ant

Apache Ant est une bibliothèque Java et un outil en ligne de commande dons la mission est de piloter des processus décrits dans des fichiers de construction en tant que cibles et points d'extensions dépendant les uns des autres.

Là encore ça sent le professionnalisme. Les fichiers Ant sont des sortes de Makefiles mais écrits en XML. Faut-il le préciser, Ant est lui aussi un outil du monde Java.

Gradle

Accélérez la productivité des développeurs
Depuis les applications mobiles aux micro-services, des petites startups aux grandes entreprises, Gradle aide les équipes à construire, automatiser et livrer de meilleurs logiciels, plus rapidement.

Je te laisse deviner à quel langage est destiné cet outil.

Gradle est l'outil de référence pour les builds des applications Android et c'est donc dans ce cadre que j'ai pu l'utiliser. Les scripts Gradle sont écrits en Groovy, un langage que je n'ai jamais utilisé par ailleurs. Perso je trouve pas ça génial mais c'est peut-être simplement parce ce que c'est loin de ce que l'on fait en C++.

Les trucs qui me fatiguent le plus avec Gradle sont d'abord le temps de compilation. La compilation du projet Java de nos jeux, une partie qui contient pourtant peu de code, prend quasiment une minute. L'autre souci est de trouver de la doc claire et facile à digérer. La doc officielle représente à peu près 24% du web^{[référence nécessaire]}, ce qui fait que la moindre interrogation demande déjà plusieurs heures de lectures, et les exemples de StackOverflow et divers blogs sont assez disparates.

Que choisir

Déjà douze outils et rien n'a l'air de dominer le marché :/ Sans doute faudrait-il inventer un nouvel outil pour les remplacer tous, quelque chose d'hyper rapide, évolutif, mais aussi adapté aux processes de déploiement intraprocéduraux sur concentrateur décentralisés pour les plus professionnels d'entre nous, avec des scripts dans un langage populaire, type GOTO++.

Malgré tout ce choix je n'ai rien trouvé qui résolve mon problème : générer un projet pour iOS, Android, Linux et OSX avec un seul script. Si vous avez une idée, ça m'intéresse.

# FastBuild

Posté par abriotde (site web personnel, Mastodon) le 15 juin 2018 à 02:42. Évalué à 6.

Très bon article. Certes, je pense que CMake domine largement et à juste titre

Pour moi FastBuild n'est pas un concurrent direct. Il est destiné aux grandes entreprises avec un voire des serveurs dédiés à la gestion de code : CVS (type GIT), tests automatiques et compilation multiplateformes. Ce qu'apporte alors FastBuild ce n'est pas de générer des makefile, c'est de lancer les compilations en parallèle sur différents serveurs avec lancement des tests automatiques.

Je sais que par exemple Google a système de ce type.

Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# Xcode

Posté par groumly le 15 juin 2018 à 05:02. Évalué à 4.

Pour compiler une application pour iOS il faut nécessairement un projet Xcode

Ca simplifie très largement la tâche, mais Xcode se contente essentiellement de lancer des commandes à droite à gauche.
La compilation en soi est pas plus compliquée que pour des libs, les assets catalogs doivent pouvoir se gérer sans trop de problèmes. La ou ça se corse, comme on dit à Bastia, c’est pour construire le reste, à savoir les entitlements, les on demand assets, et ce genre de merdier. L’ipa se génère facilement (c’est juste un zip avec une structure de dossiers spécifiques), et de ce que je m’en rappelle, il est possible de re-signer un ipa avec codesign.

Après, oui, c’est clairement une énorme perte de temps, surtout que Xcode est plutôt pas mauvais du tout sur la gestion de projets. Et se scripte aussi très bien.

Linuxfr, le portail francais du logiciel libre et du neo nazisme.
- [^] # Re: Xcode
  
  Posté par abriotde (site web personnel, Mastodon) le 15 juin 2018 à 08:11. Évalué à 2.
  
  Oui enfin comme dit dans l'article c'est la même chose que GNU Make pour Mac. Le but est là de chercher qqchose qui va nous épargner cette écriture fastidieuse et qui sera multiplateformes, pas la même étape…
  
  Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# Analyse très subjective!

Posté par Ely le 15 juin 2018 à 06:06. Évalué à 10.

Je n'ai jamais utilisé Ninja mais si jamais mes builds devenaient très lents je n'hésiterais pas à y jeter un coup d'œil. À moins que je ne passe à Meson.

Ninja n'est pas un remplacement de Meson ou de CMake. Par contre, ces deux derniers peuvent générer des fichiers ninja plutôt que des Makefile.

Tu aurais pu aussi parler des build system utilisés par chromium, GN et anciennement GYP (les deux génèrent des fichiers de build ninja).

En ce qui concerne les projets open-source C/C++, beaucoup effectuent la transition vers Meson+Ninja ces temps-ci.
- [^] # Re: Analyse très subjective!
  
  Posté par EmmanuelP le 15 juin 2018 à 08:09. Évalué à 4.
  
  Effectivement, c'est dommage de passer à côté de ninja et meson. Surtout pour un utilisateur de CMake en ce qui concerne ninja. Il suffit d'ajouter '-G Ninja' à l'appel de cmake pour profiter de la rapidité de ninja.
  
  Au sujet de meson, les développeur ont pris pour principe de ne pas faire de meson un langage de programmation. La conséquence est de faciliter la prise en main, et de rendre plus clair les fichiers de configuration de compilation. Ajouté à ça, la documentation est complète et bien fichu.
  - [^] # Re: Analyse très subjective!
    
    Posté par Julien Jorge (site web personnel) le 15 juin 2018 à 08:47. Évalué à 4.
    Alors suite à ton commentaire j'ai fait le test sur iscool::core et le gain n'est pas flagrant.
```
$ time make -j 4
real    0m29,490s
user    1m36,778s
sys 0m5,436s

$ time ninja -j 4
real    0m28,451s
user    1m39,555s
sys 0m4,701s
```
    C'est peut-être un projet trop simple, pas assez gros. D'expérience le changement le plus efficace pour accélérer les builds a été de passer aux single compilation units (SCU), où on inclut plusieurs .cpp dans un seul pour les compiler en une seule fois et d'utiliser des instanciations explicites de templates. Après ça je n'ai pas vu de gain radical.
    
    Quelqu'un a-t-il vu une comparaison de temps de build de projets utilisant des SCU avec Ninja, Make ou autre ? Il y a bien ce comparatif sur le site de Meson mais on ne parle pas de SCU ici.
    - [^] # Re: Analyse très subjective!
      
      Posté par serge_sans_paille (site web personnel) le 15 juin 2018 à 09:07. Évalué à 5.
      
      C'est surtout lors des rebuilds que ninja brille (curieux pour une profession de l'ombre, n'est ce pas ?). Comme le dit cet article c'est surtout valable pour les softs de grosse taille, mais à ce niveau ça devient significatif.
      
      Une présentation par le dev de meson qui complète bien ce journal.
      - [^] # Re: Analyse très subjective!
        
        Posté par pulkomandy (site web personnel, Mastodon) le 15 juin 2018 à 10:07. Évalué à 10.
        
        Je plussoie complètement l'utilisation de ninja. Juste pour le plaisir de le lancer une deuxième fois quand le build est fini et de le voir dire tout de suite "nothing to do". Sur un projet comme WebKit, make dans la même situation mets chez moi presque une minute pour arriver à la même conclusion.
        
        Autres avantages:
        - Pas besoin de choisir un -j à la main comme avec make, ninja surveille le system load et s'ajuste tout seul (en tenant compte de la charge CPU effective, donc il lancera plus de jobs en parallèle si la compilation est limitée par les accès disques, et moins si elle est limitée par le CPU ou si on fait autre chose sur la machine pendant ce temps).
        - Affichage correct de la sortie de la compilation, sans mélanger la sortie de différent threads
        - Affichage du nombre de cibles à compiler, ce qui permet de savoir où on en est dans le build du projet
    - [^] # Re: Analyse très subjective!
      
      Posté par liberforce (site web personnel) le 15 juin 2018 à 11:20. Évalué à 3.
      
      Les SCU sont appelées unity builds dans Meson.
      - [^] # Re: Analyse très subjective!
        
        Posté par liberforce (site web personnel) le 15 juin 2018 à 12:19. Évalué à 10. Dernière modification le 15 juin 2018 à 12:19.
        
        Je te conseille aussi de lire les objectifs de Meson et ceux de ninja.
        
        Meson ce n'est pas que les performances (pour beaucoup dues à ninja):
        - lisibilité du code
        - disparition des problèmes de quoting de CMake
        - activation des warnings par défaut (parce que les débutants ne savent pas qu'il faut les activer, et ne le font donc pas, alors que ce sont ceux qui en ont le plus besoin)
        - obligation de fait du build out-of-tree, parce que les développeurs peuvent casser le out-of tree en ne testant que le in-tree
        - unique backend ninja: le choix a été fait de ne pas utiliser make, mais ninja qui est plus restreint et plus spécialisé. ninja ne gère que les dépendances, quitte à faire des fichiers verbeux, mais qui ne contiennent pas de logique à évaluer (pas de scripts bash, etc.). En contrepartie, on utilise un générateur de fichier de build ninja, comme Meson ou CMake.
        - génération de fichiers pour Xcode ou Visual Studio
        - gestion de la cross compilation
        - utilisation massive de pkg-config pour la gestion de dépendances
        - gestion de sous projets, ce qui permet de télécharger et builder GTK+ et toutes ses dépendances en une passe.
        - gestion des SCU ou « unity builds »
        
        Ensuite ce n'est pas une solution magique. Il y a encore des soucis, et j'avais entendu que la gestion d'Android n'était pas son fort, donc ce n'est peut être pas adapté à ton besoin. Mais cela a été assez pour convaincre de nombreux projets de l'utiliser (en migration ou compltément de leur ancien build system):
        - GStreamer
        - Tracker
        - GNOME
        - Shotwell
        - Mesa
        
        Mais aussi Xorg, libinput, et d'autres…
        
        [^] # Re: Analyse très subjective!
        
        Posté par claudex le 16 juin 2018 à 10:59. Évalué à 8.
        
        parce que les débutants ne savent pas qu'il faut les activer, et ne le font donc pas
        
        Ou ils pensent que c'est fait d'office. Personnellement, quand j'ai commencé le C avec gcc, je ne comprenais pas qu'on ne m'affiche pas les warning par défaut.
        
        « 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: Analyse très subjective!
        
        Posté par Meku (site web personnel) le 16 juin 2018 à 14:08. Évalué à 3.
        
        C'est étonnant d'ailleurs que ce comportement par défaut (warnings inactifs) subsiste encore aujourd'hui.
  - [^] # Re: Analyse très subjective!
    
    Posté par Chuck #1 le 09 juillet 2018 à 16:47. Évalué à 1.
    
    Une page du wiki de KDE explique très bien l'utilisation de CMake associé à make ou ninja pour construire la suite bureautique Calligra (ou seulement une partie comme Karbon) en utilisant un dossier de build dédié pour ne pas polluer les sources. Pour la construction initiale, make et ninja se valent si le bon nombre de processus a été passé en option à make. Pour reconstruire une application après une modification mineure, il n'y a pas photo, ninja est au moins 10 fois plus rapide (ninja install est aussi plus rapide que make install). Il n'y a pas besoin de changer les CMakeLists.txt pour passer de make à ninja, il suffit d'ajouter l'option -G"ninja" à CMake.
    
    Cette signature est publiée sous licence WTFPL
# Et les outils spécialisés pour un langage spécifique

Posté par Michaël (site web personnel) le 15 juin 2018 à 07:17. Évalué à 4.

Il y a aussi plein d'outils de build non génériques (du type qui compile tout ton projet pour le projet X avec un minimum de configuraiton mais qui est tellement chiant è étendre qu'on doit faire de efforts incroyables pour ajouter quoique ce soit à la procédure).

Pour les amateurs de Makefile il y a BSD Make (hachement mieux que GNU Make)et mes macros BSD Owl (projet hobby mais bien portable)

Les autotools sont surtout intéressants si on déploie sur des systèmes très hétérogènes – même si la chance de tomber sur un UNIX exotiques doit avoir sensiblement diminué dans les 20 dernières années. Ce qu'il faut comprendre avec les autotools est que GNU Make est surtout un backend pour automake – mais à programmer à la main, c'est infernal – et en ce qui concerne autoconf, que M4 est un langage assez bizarre (ça ressemble à TeX au niveau de l'évaluation) mais qu'on peut aussi écrire du shell script normal dans son fichier autoconf!
# Meson et Ninja

Posté par gnumdk (site web personnel) le 15 juin 2018 à 08:35. Évalué à 6.

Ici, j'utilise Meson et Ninja, pour moi Meson c'est la partie autotools et Ninja la partie Makefile, non?

Et franchement, c'est vraiment top.
# build sous android

Posté par serge_sans_paille (site web personnel) le 15 juin 2018 à 08:59. Évalué à 3.

Côté Android la compilation du code C++ se fait avec l'outil ndk-build, qui est en réalité une interface à GNU Make

On notera que depuis quelques temps, ils offrent aussi une intégration à CMake.
- [^] # Re: build sous android
  
  Posté par David Demelier (site web personnel) le 15 juin 2018 à 16:13. Évalué à 3. Dernière modification le 15 juin 2018 à 16:13.
  Et CMake en natif (sans passer par celui du ndk) supporte la cross-compilation pour Android en seulement quelques variables:
```
    cmake .                                     \
        -DCMAKE_SYSTEM_NAME=Android             \
        -DCMAKE_SYSTEM_VERSION=21               \
        -DCMAKE_ANDROID_NDK=/opt/android/ndk    \
        -DCMAKE_ANDROID_ARCH_ABI=armeabi-v7a
```
  git is great because linus did it, mercurial is better because he didn't
# Cmake non ?

Posté par Frédéric Heulin le 15 juin 2018 à 08:59. Évalué à 1.

Il semble qu'il existe :
- un generator xcode pour cmake
- une intégration cmake prévue dans gradle.
Donc un moyen de gérer avec CMake en somme ?
- [^] # Re: Cmake non ?
  
  Posté par Julien Jorge (site web personnel) le 15 juin 2018 à 09:37. Évalué à 2.
  
  En dehors de l'excuse « pas-le-temps-après-tout-ça-marche » nous n'avons pas encore remplacé Premake par CMake car il y a des subtilités dans la génération du projet XCode dont j'ignore si elles sont gérables par CMake. Je parle de patches que nous avons dû appliquer à la génération du pbxproj dans Premake.
  
  Tout d'abord il y a le fait que nous utilisons encore la sélection manuelle du provisioning profile. Il faut mettre la propriété ProvisioningStyle = Manual dans les attributes.TargetAttributes des targets dans le pbxproj.
  
  Ensuite il y a les capabilities (push notifications et autres). Il faut les lister dans SystemCapabilities.
  
  Nous avons aussi dû ajouter une option SKIP_INSTALL sur les libs pour éviter qu'elles soient embarquées dans l'ipa.
  
  Enfin nous avons dû ajouter un moyen de marquer les frameworks comme optionnels afin de pouvoir lancer l'app sur de vieux appareils qui n'ont pas l'OS nécessaire pour la fonctionnalité (par exemple quand ReplayKit est arrivé nous voulions que l'application puisse se toujours se lancer sur les versions précédentes d'iOS. Nous testons alors à l'exécution si le framework est disponible).
  
  Tous ces problèmes ont été trouvés au fil de l'eau et le système de plugins en Lua de Premake nous a permis de trouver des solutions assez rapidement. Je ne sais pas si cela aurait été aussi simple avec CMake.
  - [^] # Re: Cmake non ?
    
    Posté par pulkomandy (site web personnel, Mastodon) le 15 juin 2018 à 10:10. Évalué à 4.
    
    Je précise que la communauté cmake (et son canal IRC) est pas mal réactive et disponible pour faire les modifications quand c'est nécessaire. Si tu n'es pas forcé de supporter de vieilles versions de cmake, tu pourras donc obtenir de l'aide pour régler ces problèmes, et s'il y a lieu, ce sera intégré dans cmake directement.
    
    Je mentionne aussi au passage le très pratique cpack, qui permet de générer un .deb, un .rpm et/ou un installeur windows sans trop s'embêter. Mais peut être pas encore les .apk (ce n'est pas trop compliqué d'ajouter le support d'un nouveau format de distribution à cpack, cela dit…)
- [^] # Re: Cmake non ?
  
  Posté par reno le 19 juin 2018 à 10:48. Évalué à 3.
  
  Cmake est un méta système de build donc quand tu as un problème il faut regarder les Makefile et remonter.
  
  Si tu as besoin de la portabilité OK, mais au travail on utilise CMake alors qu'on est cible seulement Linux et là rajouter une couche supplémentaire je pense que ça complique plus la vie qu'autre chose.
  En ce moment, je suis en train d'essayer de comprendre pourquoi les cibles sont compilés dans un ordre différent d'une compilation à l'autre, je galère..
  
  Certes construire un bon GNU Makefile demande pas mal d'effort mais en partant d'un Makefile 'modèle' on y arrive (enfin il faut quand même trouver le 'bon' modèle).
  
  Pour ce qui est de la critique "Par exemple, si j'ajoute une option qui concerne l'édition des liens, celle-ci ne sera pas refaite par défaut." et bien ajouter une dépendance qui dis que si le Makefile est + récent que les target tu refais tout ne me parait pas compliqué.
# Make mon ami

Posté par Sygne (site web personnel) le 15 juin 2018 à 09:26. Évalué à 6.

J'avoue que les deux critiques de make exposées dans le journal me laissent coi…

Il m'arrive encore de créer des petits Makefiles manuellement mais c'est vite pénible.

C'est pas faux ! Mais d'un autre côté, je n'ai pas l'impression que l'on ait à modifier le makefile bien souvent, sinon pour ajouter une dépendance, ce qui prend trois secondes. Donc ce temps perdu peut vite ressembler à du temps gagné si, par ailleurs, (BSD)make fait le boulot.

Un autre point difficile à gérer concerne la dépendance au fichier Makefile lui-même.

Trop gros, passera pas.
- [^] # Re: Make mon ami
  
  Posté par liberforce (site web personnel) le 15 juin 2018 à 18:22. Évalué à 2.
  
  Mais d'un autre côté, je n'ai pas l'impression que l'on ait à modifier le makefile bien souvent, sinon pour ajouter une dépendance, ce qui prend trois secondes.
  
  Sauf quand on l'écrit pour la première fois. Et tu as beaucoup de chances en cherchant sur le net de tomber sur des Makefiles bogués, et donc d'avoir à modifier autre chose que juste une dépendance.
  - [^] # Re: Make mon ami
    
    Posté par thaddeus (site web personnel) le 21 juin 2018 à 00:16. Évalué à 3.
    
    tu as beaucoup de chances en cherchant sur le net de tomber sur des Makefiles bogués
    
    Pour un projet simple, un Makefile de quelques lignes suffit. Pour un projet complexe, le Makefile sera probablement trop spécifique pour utiliser un fichier copié/collé depuis internet.
    
    Dans les deux cas, j'ai du mal à comprendre qu'on préfère chercher des exemples tout fait sur le net plutôt que de lire la doc. Dans mes souvenirs, celle de Make est plutôt bien faite. C'est dommage de s'en passer, pour ensuite devoir déboguer le travail de quelqu'un d'autre.
- [^] # Re: Make mon ami
  
  Posté par steph1978 le 10 juillet 2018 à 23:46. Évalué à 3.
  
  Il m'arrive encore de créer des petits Makefiles manuellement mais c'est vite pénible.
  
  Donc ce temps perdu peut vite ressembler à du temps gagné si, par ailleurs, (BSD)make fait le boulot.
  
  Et pourtant…
  
  J'ai écrit un make tout simple pour compiler du markdown en html.
  D'habitude, je faisais ça en bash mais c'est verbeux et je voulais essayer make car je trouve les concepts très bons : recette et dépendances entre objets produits.
  J'ai trouvé la syntaxe très peu intuitive :
  * j'utilise dollar inférieur ou dollar point d'interrogation ?
  * comment je récupère le nom du fichier sans son extension
  
  Il m'arrive aussi très souvent de builder des logiciels beaucoup plus conséquents dont je télécharge les sources. Aucun n'utilise directement les Makefiles. Ils sont générés par des outils de plus haute niveau. Et quand on voit le Makefile produit, il serait impossible de le maintenir à la main.
  
  Donc ça marche mais pour des choses pas trop compliquées.
  
  Un autre point difficile à gérer concerne la dépendance au fichier Makefile lui-même.
  
  Trop gros, passera pas.
  
  Et pourtant si dans le Makefile, tu changes une recette (pas une dépendance) et que tu lances make, il te dira qu'il n'y a rien à faire.
  
  Je trouve les deux critiques initiales tout à fait valides.
  - [^] # Re: Make mon ami
    
    Posté par Sygne (site web personnel) le 11 juillet 2018 à 12:42. Évalué à 4.
    Make, c'est un vrai langage de programmation. Et comme tout langage de programmation, si on ne l'apprend pas, on n'arrive pas bien à l'utiliser. Certes, sa syntaxe est pluôt datée, et la documentation de Gnu Make est particulièrement pas efficace, mais Make reste, malgrès ces défauts, un langage plutôt facile à appréhender. Et si Gnu Make est mauvais, BSD Make est réputé meilleur…
    
    Pour récupérer le nom d'un fichier sans son extension, Gnu make propose $(basename target), par exemple $(basename $<). Gnu Make propose aussi la possibilité d'effectuer des substitutions sur le nom des variables, ce qui peut peut-être répondre à ton besoin:
```
MYFILES = alpha beta gamma
MYHTML = $(MYFILES:%=%.html)
MYMKD = $(MYFILES:%=%.mkd)
MYDIR = /path/to/my/dir
MYTARGET = $(MYHTML:%=$(MYDIR)/%)
```
    Pour que le makefile soit pris en compte lors de la génération de l'arbre des dépendances, on l'indique explicitement comme dépendance:
```
%.html: %.mkd Makefile
    markdown $< $@
```
    Si cette syntaxe n'est pas amicale, on devrait pouvoir faire ainsi:
```
%.html: %.mkd
    markdown $< $@

%.html %.pdf %.odt %.dvi: Makefile
```
# Mon expérience à deux balles

Posté par Miguel Moquillon (site web personnel) le 15 juin 2018 à 09:50. Évalué à 5.

Ouep, l'enfer des outils de build s'ouvre dès que l'on veut construire un logiciel destiné à plusieurs plate-formes d'exécution. Il y a eu des langages mutli plate-formes qui ont été développées (Lisp, Smalltalk, Java, …) pour éviter, entre autre, ce genre de problèmes, mais ça n'a jamais vraiment marché parce qu'il y a toujours une plate-forme, le vent en poupe, qui ne joue pas leur jeu. Ou alors ça ne rempli pas les contraintes du logiciel (le plus souvent la performance) sur une ou plusieurs plate-formes cibles (mais ce critère relève peu ou prou aussi du premier, à savoir de jouer le jeu ; voir l'exemple raté des machines Lisp).

Dans mon cas, après avoir développé en C++ jusqu'en 2003 où on utilisait massivement des Makefiles, je me suis mis à Java jusqu'à encore aujourd'hui. Au début, on utilisait Ant (qui, comme tu l'as si bien écris, est du Makefile en XML). Maintenant on utilise Maven et bien que non exempte de défauts, je trouve que c'est un outil formidable surtout sur des gros, très gros projets ou lorsque les projets sont composés de plusieurs langages et ressources (Java, Groovy, Javascript, CSS, …). On utilise aussi du Gradle mais là c'est plus comme base pour concevoir des installateurs et configurateurs d'applications sur serveurs que comme système de build. A côté de ça je fais aussi un peu d'Haskell. Ce dernier a son propre outil de build (pardon ses propres outils de build) et ce n'est pas plus mal (j'adore slack). Les pires systèmes de build que j'ai pu utiliser restent quand même ceux du monde Javascript … Le meilleur que j'ai trouvé est celui du monde Smalltalk : il n'y en a pas ! Ou plus exactement, comme il ne s'appuie pas sur une approche de programmation et de construction orientée fichier, les problèmes adressés ne sont pas les mêmes et, au regard de ma piètre expérience avec, j'ai m'y suis pris beaucoup moins la tête. Mais je m'égare …

Pour répondre à ta question, dans mon ancienne boite, j'ai vu des équipes qui développaient des projets multi plate-formes (desktop, mobile Androïd, …) utiliser Maven comme outil de build centralisé. Par contre, ne m'étant jamais vraiment intéressé à ce problème, je ne leur ai jamais demandé leur retour là dessus. En tout cas, il semble qu'il existe des plugins Maven pour construire des projets iOS : j'ai trouvé ça https://github.com/letsdev/maven-ios-plugin
- [^] # Re: Mon expérience à deux balles
  
  Posté par totof2000 le 15 juin 2018 à 12:54. Évalué à 0.
  
  Pour moi, le gros défaut der Maven, c'est le XML : ça rend le truc difficile à lire et à comprendre.
  - [^] # Re: Mon expérience à deux balles
    
    Posté par Yves (site web personnel) le 15 juin 2018 à 13:57. Évalué à 6.
    
    Bon, je réponds ici, mais c’est une réponse générale, en fait… (rien de personnel)
    
    Eh, les gars, faut dépoussiérer le cerveau, si la lecture d’un pom.xml vous incommode sous prétexte que c’est du XML !
    
    C’est comme si vous organisiez un entretien pour un développeur full-stack multi-plateforme et tout, et là, le candidat vous sort « Alors, euh, en fait, euh, HTML je comprends pas trop, c’est trop dur à lire… ». Bonne change pour lui mettre un hexdump sous les yeux ou lui faire débuguer un problème d’encoding !
    
    En revanche, oui, se plonger dans Maven n’est pas forcément simple, mais c’est le prix à payer pour un outil très complet et… professionnel en effet.
    
    [Sorry for the rant… -->[]
    - [^] # Re: Mon expérience à deux balles
      
      Posté par ocroquette le 09 juillet 2018 à 07:55. Évalué à 0.
      
      Il y a plusieurs différences entre le HTML et les pom.xml:
      - les pom.xml, il faut non seulement les lire mais aussi les écrire
      - lire, comprendre et/ou modifier le fichier de build est une tache normale d'un développeur, pas vraiment pour le HTML
      - la compréhension des pom.xml requiert la compréhension des plugins utilisés, qui s'assimilent parfois à de la magie
      - [^] # Re: Mon expérience à deux balles
        
        Posté par barmic le 09 juillet 2018 à 13:01. Évalué à 1. Dernière modification le 09 juillet 2018 à 13:01.
        
        la compréhension des pom.xml requiert la compréhension des plugins utilisés, qui s'assimilent parfois à de la magie
        
        Euh… Il faut comprendre ce qu'on fait. Que tu veuille utiliser un truc que tu connais pas trop pour apprendre c'est cool, mais alors tu ne peux pas reprocher que c'est magique. Les plugins maven sont triviaux. En écrire est vraiment très simple. Si ça reste de la magie c'est que tu ne cherche pas à en savoir plus sur ton outil. Ce n'est pas forcément grave, mais ne va pas reprocher à l'outil d'être magique.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par ocroquette le 09 juillet 2018 à 19:18. Évalué à 1.
        
        "Magie" n'était probablement pas le terme le plus juste, disons plutôt que ce n'est pas naturellement transparent. C'est d'ailleurs un reproche récurent qui lui est fait, au hasard: https://johlrogge.wordpress.com/2010/12/14/why-i-dont-like-maven/
        
        Les plugins sont peut-être triviaux à écrire, mais je préfère avoir l'option de ne pas avoir à en écrire, ce que me permettent par exemple CMake ou Gradle.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par barmic le 10 juillet 2018 à 08:47. Évalué à 1.
        
        […] au hasard […]
        
        Au hasard quelqu'un qui parle de maven 2 et qui dit clairement qu'il n'a pas essayé maven 3 et que ça a peut être changé (en même temps l'article a 8 ans…).
        
        Une partie de ses critiques sont vraies, je dis simplement que les plugins sont simples.
        
        Les plugins sont peut-être triviaux à écrire, mais je préfère avoir l'option de ne pas avoir à en écrire[…]
        
        La question n'est pas d'avoir à les écrire, mais à les comprendre. J'ai expliqué qu'il était facile d'en écrire simplement pour expliquer que si vraiment tu as un problème avec l'un d'entre eux, tu peux télécharger son code source et le lire, ça n'est pas incroyable.
        
        […] ce que me permettent par exemple CMake ou Gradle.
        
        En terme de mélange de choux et de carottes… CMake ne fait pas de build donc effectivement tu n'a pas à écrire de plugin (je ne sais même pas si cette notion existe pour eux), tu va par contre peut être devoir écrire une macro spécifique pour certaines dépendances. Gradle si tu as plus de quelques lignes de groovy, je pense qu'il est plus sage d'écrire un vrai plugin qui sera testé plutôt que de fourrer un gros bout de code directement dans ton fichier de build. Tu as un plugin maven connu qui permet aussi d'utiliser du scripting ant (les scripts ant c'est pas fou, mais ça fait le taff).
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par ocroquette le 10 juillet 2018 à 13:56. Évalué à 1. Dernière modification le 10 juillet 2018 à 13:56.
        
        Plutôt que de contredire tes interlocuteurs systématiquement, tu pourrais t'intéresser à leurs arguments et demander des précisions si tu ne les comprends pas. Et utiliser un autre ton.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par barmic le 12 juillet 2018 à 11:51. Évalué à 0.
        
        […] tu pourrais t'intéresser à leurs arguments […]
        
        J'veux bien, mais je n'ai trouvé que des assertions (y compris dans le liens que tu donne d'ailleurs).
  - [^] # Re: Mon expérience à deux balles
    
    Posté par barmic le 15 juin 2018 à 14:25. Évalué à 6.
    Je rejoins Yves c'est un faux problème. XML est largement plus facile à lire que json ou yaml par exemple. Son problème c'est qu'à être très explicite il en devient verbeux. Mais le xml étant trivial à manipuler par un programme tous les éditeurs qui s'y intéressent un minimum ont des méthodes pour le présenter et le manipuler de la façon qu'ils le souhaite (les code snippet d'intellij sont cool pour ça par exemple).
    
    Ils aurait pu choisir un format xml plus compact ça n'aurait pas fait de mal, mais affirmer « c'est du xml bouh ! c'est pas bien ». C'est un leurre, tous les formats qui sont très utilisés rencontrent des problèmes que xml avait réfléchis au départ :
    - json aimerait bien avoir de la description de format, mais ne sait pas trop comment s'y prendre du coup il tatonne entre plusieurs façon
    - yaml est une plaie à écrire sa syntaxe possède des subtilités qui peuvent rendre fou si ton parseur ne présentent pas bien les erreur en question
    - groovy (utilisé par gradle) ne permet pas de validation forte d'un fichier de build et sera probablement, à terme, remplacé par kotlin
    Les autres outils de builds réinventent des formats/syntaxes, maven a choisi de ne pas réinventer la roue ça me paraît être quelque chose de plutôt malin.
    - [^] # Re: Mon expérience à deux balles
      
      Posté par totof2000 le 15 juin 2018 à 14:53. Évalué à 1.
      
      Arrêtez les conneries les gars : un xml, c'est illisible. En plus c'est imbitable quand tu fais des diffs avec un gestionnaire de version tel que git. Je suis confronté à Maven ici au taf, et j'ai aussi à bosser avec du yaml, et définitivement, yaml est bien plus lisible que xml.
    - [^] # Re: Mon expérience à deux balles
      
      Posté par wismerhill le 15 juin 2018 à 22:33. Évalué à 8.
      
      Et surtout, json ne prévoit pas les commentaires!
      C'est un format simple et pratique pour échanger des données structurées (mais pas trop quand même) entre programmes hétéroclites, mais c'est une aberration d'utiliser ça pour un fichier de configuration. (composer, c'est à toi que je pense)
      - [^] # Re: Mon expérience à deux balles
        
        Posté par flan (site web personnel) le 15 juin 2018 à 23:22. Évalué à 3. Dernière modification le 15 juin 2018 à 23:25.
        
        J'aime bien l'idée d'Apple pour les fichiers de configuration (les .plist). Il s'agit un seul format logique qui
        
        correspond globalement à une table clefs-valeurs (sachant qu'une valeur peut elle-même être une table clef-valeur),
        
        est utilisé par tous les outils Apple (fantastique : ça évite d'écrire un parseur par application à configurer ! ),
        
        possède plusieurs représentations en tant que fichier (binaire, XML voire JSON) — mais en vrai, on s'en fout un peu —,
        
        peut être édité par pas mal d'outils (y compris vim avec un plugin, mais ça donne un fichier XML),
        
        peut être lu ou écrit partiellement en ligne de commande (on peut modifier la valeur d'une seule clef ou en exporter quelques unes),
        
        a des bibliothèques utilisables dans pas mal de langages (dans la bibliothèque standard de Python, par exemple).
        
        Il manque la possibilité d'ajouter des commentaires, malheureusement.
        
        Au final, je trouve que JSON, XML ou autre, ça ne change pas grand-chose au final. Au pire, il suffit d'un plugin dans l'éditeur pour le transformer en quelque chose d'utilisable par un être humain le temps de l'édition.
      - [^] # Re: Mon expérience à deux balles
        
        Posté par Marotte ⛧ le 16 juin 2018 à 19:48. Évalué à 4.
        
        Je ne vois pas en quoi ce serait plus une aberration d’utiliser JSON pour un fichier de configuration qu’utiliser XML ou Yaml… Peux-tu développer ?
        
        Je trouve Yaml cent fois plus lisible qu’un XML, même compacte. Le problème de Yaml a été donné plus haut : ce sont les subtilités de la syntaxe, qui font qu’on peut perdre une heure à cause d’une seule espace mal placée quand on a pas trop l’habitude. Le JSON est entre les deux question lisibilité, selon moi.
        
        La question qui me vient : quel est selon toi le format à privilégier pour un fichier de configuration d’une application (j’entends un fichier destiné à être édité par un humain) ? Le format INI ? Un clé/valeur encore plus simple ?
        
        XML, ou tout langage utilisant le principe de balise ouvrante/fermante, sera pénible à manipuler par un humain. Un langage qui utilise l’indentation et le concept de liste apparaîtra comme plus simple (et le sera effectivement).
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par flan (site web personnel) le 16 juin 2018 à 20:57. Évalué à 4.
        
        Je trouve que le .ini est le plus simple et le plus lisible et le plus intuitif, mais il ne permet pas (de base) les types complexes (listes ou dictionnaires clefs-valeurs) contrairement au JSON ou au Yaml, et n'est pas typé.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par groumly le 16 juin 2018 à 21:34. Évalué à 4.
        
        Pas de commentaires, les objets étant en fait des hashmap, la manipulation automatique va réordonner les champs, ce qui fout en l’air les diffs, et le typage est une arme à double tranchant (parce que tu sais pas ce que l’outil attends, ni s’il supporte le transtypage automagique string <-> number). Et pour des cas particulièrement extrême, l’imprecision intrinsèque des nombres en json peut te donner des résultats étonnant (Bon, c’est très improbable que ça arrive, mais c’est possible).
        
        Je dirais pas que c’est une aberration, mais c’est un format qui ne marchera que dans certains cas précis.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par Claude SIMON (site web personnel) le 17 juin 2018 à 14:39. Évalué à 2.
        
        Ce qui manque à JSon, et à Yaml aussi, qui fait que je leur préfère XML pour les fichiers de configuration, ce sont les espaces de noms…
        
        Pour nous émanciper des géants du numérique : Zelbinium !
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par amdg le 18 juin 2018 à 14:22. Évalué à 4.
        
        Le format TOML est un INI sous stéroïde. C'est simple a écrire pour un humain, ça supporte les commentaires et les structures de données de bases (liste, dictionnaire) les dates (YAML ne fait pas ça je crois).
        
        C'est utilisé par quelques gros projets (notamment Cargo, l'outil de build de Rust justement) et on trouve des parseurs matures dans plein de langages.
        
        Je recommande vraiment d'aller y jeter un coup d’œil, c'est devenu mon format de fichier de conf favori !
        
        Pour voir une comparaison rapide et surement biaisé vis à vis de JSON, YAML et INI: https://github.com/toml-lang/toml#comparison-with-other-formats
        
        AMDG
      - [^] # Re: Mon expérience à deux balles
        
        Posté par Marotte ⛧ le 17 juin 2018 à 15:08. Évalué à 3.
        
        Pour les commentaires, l’auteur de JSON lui-même dit qu’on peut en mettre, notamment dans le cas d’un fichier de configuration. Il suffit d’ôter ces commentaires avant de parser. C’est une contrainte on est bien d’accord, mais c’est loin d’être éliminatoire.
        
        https://stackoverflow.com/questions/244777/can-comments-be-used-in-json (voir la 3e réponse : « Include comments if you choose; strip them out with a minifier before parsing or transmitting. »)
        
        Le sujet m’intéresse parce que je viens de démarrer l’écriture d’un programme et j’ai choisi JSON pour stocker la configuration. D’habitude je me contente d’un clé/valeur « maison », mais j’ai eu envie d’essayer autre chose cette fois-ci (choix fait avant la lecture de ce journal) :)
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par barmic le 17 juin 2018 à 16:39. Évalué à 7.
        
        C'est même pas un workaround, c'est comme si je disait que tu peux écrire du XML comme du JSON, il faut juste le convertir en XML avant de le donner au parseur XML…
        
        Les commentaires font partie de la syntaxe d'un langage, je ne pas avoir voulu l'implémenter est un choix. Qu'il existe des workaround très bien (je crois que certains parseurs acceptent des syntaxes de commentaires), mais on perds toute capacité d'échange.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par Marotte ⛧ le 17 juin 2018 à 19:48. Évalué à 0.
        
        c'est comme si je disait que tu peux écrire du XML comme du JSON, il faut juste le convertir en XML avant de le donner au parseur XML…
        
        Tu n’as pas l’impression d’exagérer un tout petit peu ?
        
        mais on perds toute capacité d'échange.
        
        Pour le(s) fichier(s) de configuration d’une application ce n’est pas un problème, si ?
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par flan (site web personnel) le 17 juin 2018 à 20:10. Évalué à 3.
        
        Si, ça peut être gênant si tu veux éditer la configuration de façon automatique par un programme externe (par exemple un gestionnaire de conf' qui veut uniquement modifier une seule valeur, sans toucher au reste de la configuration).
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par barmic le 17 juin 2018 à 20:20. Évalué à 2.
        
        Si tu veux laisser à l'utilisateur la possibilité d'utiliser un éditeur JSON (ou un éditeur de texte avec un plugin json).
        Ou pour lui permettre d'utiliser un linter.
        Ou pour laisser la possibilité à quelqu'un d'implémenter un logiciel compatible avec tes fichiers de configuration.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par totof2000 le 18 juin 2018 à 08:27. Évalué à -1.
        
        Bof …. Se prendre la tête et la tête des utilisateurs avec un xml illisible juste parce que potentiellement un éditeur de conf va avoir besoin de l'éditer … hum. En fait xml me pose des problèmes avec Ansible, et à l'époque ou je me suis intéressé à spacewalk, c'était la grosse galère pour gérer les confs xml également. Donc pour moi c'est un faux problème. Enfin, la gestion du xml avec un gestionnaire de conf me pose aussi de gros problèmes, pour des pseudos avantages que tu cites mais qui en pratique n'existent pas.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par totof2000 le 18 juin 2018 à 10:35. Évalué à 2.
        
        J'aimerais bien voir des cas concrets de ce genre de truc, parce que jusqu'à maintenant, je n'ai jamais vu (je ne dis pas que ça n'existe pas).
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par barmic le 18 juin 2018 à 10:49. Évalué à 6.
        
        # cat test.json { // hello "foo": "bar" } # cat test1.json { "foo": "bar" } # jq ".foo" test.json parse error: Invalid numeric literal at line 2, column 7 # jq ".foo" test1.json "bar"
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par groumly le 18 juin 2018 à 06:02. Évalué à 6.
        
        Tu n’as pas l’impression d’exagérer un tout petit peu ?
        
        Pas vraiment non. Le commentaire du en substance “écrit du json invalide, et demerde toi pour le nettoyer avant de l’utiliser”. C’est un hack crado, et ça implique d’avoir un minifier dispo.
        
        Pour le(s) fichier(s) de configuration d’une application ce n’est pas un problème, si ?
        
        Ben un peu quand même, faut que l’appli se rappelle de minifier avant de parser. Sans compter que pas mal d’éditeur vaut probablement tirer la gueule sur les commentaires et avoir des problèmes avec la coloration syntaxique.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
      - [^] # Re: Mon expérience à deux balles
        
        Posté par devnewton 🍺 (site web personnel) le 18 juin 2018 à 09:33. Évalué à 1.
        
        Et surtout, json ne prévoit pas les commentaires!
        
        Il y a la convention _${field}_comment :
        { "_plonkes_comment": "plonke les pénibles" "plonkes": ["zenitram", "devnewton"] }
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par groumly le 18 juin 2018 à 09:52. Évalué à 6.
        
        org.codehaus.jackson.map.exc.UnrecognizedPropertyException:
        Unrecognized field "_plonkes_comment" (Class LesPenibles), not marked as ignorable
        at [Source: java.io.StringReader@1198891; line: 1, column: 13]
        
        Ya pas à tortiller du cul pour chier droit. Les commentaires doivent avoir un support natif du language pour être utilisables et utilisés.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par devnewton 🍺 (site web personnel) le 18 juin 2018 à 10:10. Évalué à -4.
        
        Un parseur qui plante s'il y a un champ non prévu? C'est pas très restful tout ça!
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par barmic le 18 juin 2018 à 10:35. Évalué à 2.
        
        Ça tombe bien JSON et REST sont 2 choses différentes. Dans le cadre de fichiers tu as besoin de commentaires, alors que dans des ws ça n'est pas nécessaire.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par groumly le 18 juin 2018 à 16:53. Évalué à 2.
        
        En fait, t’as vraiment aucune idée de la problématique dont on parle…
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
    - [^] # Re: Mon expérience à deux balles
      
      Posté par claudex le 16 juin 2018 à 11:14. Évalué à 6.
      XML est largement plus facile à lire que json ou yaml
      
      Que json, oui. Yaml est très lisible.
      
      dependencies: - "src/one.h" - "src/two.h"
      
      <dependencies> <dependency>src/one.h</dependency> <dependency>src/two.h</dependency> </dependencies>
      
      Par contre, en tant que format d'échange, XML est toujours intéressant.
      
      « 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: Mon expérience à deux balles
        
        Posté par barmic le 17 juin 2018 à 16:41. Évalué à 2.
        
        Tu viens de démontrer qu'il peut être lisible. Mais le fait de pouvoir écrire ta liste de 2 façon différentes, la manière de gérer des bloc de texte, le multidocument dans un même fichier, les liens au sein d'un document,… sont des trucs que j'arrive jamais à écrire du premier coup et pour relire je bloque toujours dessus avant d'arriver à bien comprendre.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par claudex le 17 juin 2018 à 17:21. Évalué à 4.
        
        Alors, on n'a pas la même définition de lisible, l'overhead du xml est bien trop gros pour rendre ça lisible. La fermeture des balises, ce n'est pas un truc intéressant dans un fichier de configuration, ça ajoute du bruit. On ne vois pas au premier coup d'œil que c'est une liste en XML non plus.
        
        « 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: Mon expérience à deux balles
        
        Posté par barmic le 17 juin 2018 à 17:56. Évalué à 3.
        
        Le mot que tu cherche c'est verbeux, ça n'a rien à voir (même hors langage informatique). Perl n'est pas verbeux, mais peux devenir illisible.
        
        Pour ce qui est de yaml, les constructions comme les références (avec * ou &), le merge de clefs,… sont des fonctionnalités très puissante, mais se font à partir de quelques caractère.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par claudex le 17 juin 2018 à 18:01. Évalué à 3.
        
        Je ne reproche pas que la verbosité. Par exemple, on ne vois pas facilement qu'il y a une liste dans le XML.
        
        « 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: Mon expérience à deux balles
        
        Posté par barmic le 17 juin 2018 à 18:12. Évalué à 1.
        
        Je ne reproche pas que la verbosité.
        
        Dans ton commentaire précédent un peu quand même tu parle du bruit.
        
        Pour les listes, l'indentation et la coloration syntaxique fonctionne bien et la réindentation est fiable comme en json (contrairement au yaml).
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par totof2000 le 18 juin 2018 à 08:51. Évalué à 1.
        
        Le mot que tu cherche c'est verbeux, ça n'a rien à voir (même hors langage informatique).
        
        Ah ben si quand même, surtout dans le cas qui nous concerne : la verbosité xml rend les fichiers xml difficile à lire. Ce n'est pas la seule raisn qui les rend difficile à lire (pour un humaion), mais ça y joue beaucoup.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par barmic le 18 juin 2018 à 10:43. Évalué à 7.
        
        Une trop grande concision est bien plus perturbante qu'une grande verbosité. C'est lassant, c'est ennuyeux tout ce que tu veux, mais ça n'est pas si impactant pour la lisibilité. Il faut prendre en compte :
        
        que tu as de la coloration syntaxique
        
        que presque toute la syntaxe est a base de la même convention <mot> tu n'a pas à comprendre que des caractères plus ou moins bizarres ont des comportements plus ou moins différents en fonction du contexte ({, }, &, *, etc).
        
        XML c'est chiant, c'est lourd, ça consomme beaucoup de ressources, tu as tellement de standard que tu as pleins de logiciels qui n'arrivent pas à toutes les respecter, ça a était utilisé pour des trucs à la con (SOAP c'est toi que je regarde). Mais ça n'est pas particulièrement moins lisible qu'un agglomérat de caractères plus ou moins abscons dans d'autres syntaxe.
        
        Et je vais arrêter là, la discussion est stérile.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par totof2000 le 18 juin 2018 à 14:46. Évalué à -2.
        
        Et je vais arrêter là, la discussion est stérile.
        
        Dans la mesure ou tu es à côté de la plaque, c'est sur.
        
        que tu as de la coloration syntaxique
        
        Non : en prod, ça m'arrive de déployer des VMs avec un envirponnement très restreint, sans éditeur me fournissant une coloration syntaxique. Imagine le délire lorsqu'il faut débugger une conf xml.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par barmic le 18 juin 2018 à 15:35. Évalué à 4.
        
        Non : en prod, ça m'arrive de déployer des VMs avec un envirponnement très restreint, sans éditeur me fournissant une coloration syntaxique. Imagine le délire lorsqu'il faut débugger une conf xml.
        
        Tu as d'autres problèmes quand tu fais ça :
        
        tu ne teste pas tes configurations
        
        tu ne versionne pas tes configurations
        
        Le format c'est le dernier de tes problèmes. Tu es peut être obligé de le faire (on va m'expliquer que dans le domaine de ne pas respecter les règles de qualité c'est normal), mais ton problème c'est clairement pas ton format. Mais si c'est ton plaisir d'éditer des fichiers avec ex pour te sentir super fort tant mieux pour toi.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par totof2000 le 18 juin 2018 à 16:46. Évalué à -2.
        
        J'ai l'impression que tu fais expres de ne pas comprendre : sur une machine de prod, quand un truc ne marche pas, je dois parfois aller voir le contenu du fichier installé pour savoir s'il est conforme à ce que j'attends, et pour faire ça, je n'ai pas forcément la possibilité d'utiliser un éditeur à coloration syntaxique.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par groumly le 18 juin 2018 à 17:03. Évalué à -3.
        
        1) on a tree bien compris, tu debuggues en prod. #yolo
        2) vraiment, t’as pas vim/emacs/whatever? Tu bosses avec “edit” sous dos 5.0?
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par totof2000 le 18 juin 2018 à 18:00. Évalué à 5.
        
        1/ eh oui, ça arrive de rechercher la cause d'un dysfonctionnement en prod, ne t'en déplaise: tous les bugs ne peuvent être reproduits en environnement de préprod, et en pratique, on n'en a pas toujours sous la main. C'est la vraie vie, ça.
        
        2/ parfois sur des machines, je n'ai pas de vim mais nano, ou alors, une version de vim qui n'inclue pas la coloration syntaxique (ubuntu par exemple), sans avoir la possibilité d'installer autre chose. Et surtout pour visualiser un fichier je préfère des commandes telles que less par exemple (ça évite la modification accidentelle des confs).
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par Kerro le 19 juin 2018 à 17:33. Évalué à 2.
        
        on a tree bien compris, tu debuggues en prod. #yolo
        
        L'immense majorité des entreprises n'ont pas la capacité d'avoir un environnement identique entre les tests et la prod. Ils ont juste de quoi coder/vérifier/débugguer sur le poste de l'unique développeur et basta.
        
        Alors certes ce n'est pas hyper compliqué (en général) d'avoir un environnement de tests parfait, mais dans les faits ce n'est pas le cas (selon le niveau du développeur, donc selon le niveau du recrutement).
        
        Et malgré cela, dans bien des cas on ne peut tester certaines choses que sur la prod car générer les mêmes conditions de charge serait trop compliqué pour une petite entreprise.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par barmic le 19 juin 2018 à 17:50. Évalué à -1.
        
        Ton vélo a un pneu complètement à plat, tu monte dessus commence à pédaler et après quelques tours de pédale tu te plains d'avoir du mal à pédaler parce que la chaîne n'est pas bien graissée. Si on te le fait remarquer tu nous explique que de toute manière t'a pas de rustine.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par groumly le 20 juin 2018 à 07:44. Évalué à 1.
        
        Bon faut savoir de quoi on parle la.
        Si l’environnent de prod c’est le WordPress de jean guy, prestataire it pour la communauté de commune de veuzons sur vologne (12 postes), oui, je comprends. Mais à ce niveau, la solution c’est ptetre plus d’outsourcer ladite instance WordPress que de se demander si json ou xml est le format adéquat.
        
        Si t’en es encore au niveau “je suis même pas sûr que machine de prod est configurée correctement alors faut vérifier à la main”, je suis à peu près sûr que ton infra s’ecroule avant que tu ne rencontre de vrais problème de charge. Comprendre par la “une charge que JMeter ne peut pas trivialement recréer depuis 3-4 laptops qui traînent dans le bureau”. Le simple fait de considérer la charge comme un problème exclue de fait la “petite entreprise sans moyens”.
        
        Si t’as reellement des problemes à simuler des conditions de charge sur un environment interne (comprendre “problèmes autre que l’incompetence“), ben mon petit doigt me dit que:
        - t’as au moins une équipe dédiée à l’infra, et on se demande bien ce qu’ils foutent s’ils sont pas foutu d’avoir au moins de la config management qui soit capable de garantir que si ça tourne en interne, ça tourne en prod.
        - ton problème de charge va clairement pas être du à “le fichier de config xml il est pas comme il devrait et faut que je me le coltine avec more, parce que tu comprends, vim ça prends trop de kB sur ma vm”
        
        Tu peux pas avoir le beurre et l’argent du beurre. Soit t’es un professionnel qui bosse dans un environment decent ou les bases de la qualité sont raisonnable (et la barre est plutôt basse dans ce milieu), soit t’es en clampin qui debugge en prod a coup de #yolo et se plaint que le xml saytropdur a debugger en prod.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par Kerro le 20 juin 2018 à 17:34. Évalué à 2.
        
        à ce niveau, la solution c’est ptetre plus d’outsourcer ladite instance WordPress que de se demander si json ou xml est le format adéquat.
        
        Écrire ça sur un site rempli de geeks/bricoleurs/curieux, c'est gonflé :-)
        Il y a un gros paquets de besoins qui sont accessibles à un bidouilleur averti. Sinon il ne faudrait jamais soulever le capot d'une distribution Linux, ne jamais dépanner Windows, etc. Toujours faire appel à un prestataire.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par barmic le 20 juin 2018 à 17:49. Évalué à 2.
        
        Écrire ça sur un site rempli de geeks/bricoleurs/curieux, c'est gonflé :-)
        
        Il se donne les moyens de lire un fichier avec son éditeur préféré parce qu'il n'y a pas de raison particulière pour qu'il s'interdise d'installer son éditeur préféré sur son serveur ou de rapatrier les fichiers sur sa machine pour les lire au calme.
        
        Le geek/bricoleur/curieux qui gère de l'HPC sans internet, ben euh… OSEF ?
        
        En plus la question était pour un outils de build à la base. Perso je build pas en prod (« Mais oui mais tu comprends pas, moi je build sur ma montre avec ma bite et mon couteau et ne pas prendre en compte mon cas d'usage c'est un affront ! ») et les builds en IC sont reproductibes sur ma machine donc je n'ai pas à aller la voir.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par groumly le 20 juin 2018 à 21:43. Évalué à 5.
        
        C'est pas trop la question. si un bidouilleur veut bidouiller, grand bien lui en prenne. Ca m'en touche une sans faire bouger l'autre.
        Par contre s'il vient m'expliquer que le xml saypabien parce que ca s'inscrit pas dans son workflow sans queue ni tete, ben on lui explique pourquoi il a tord.
        Apres, il peut accepter l'argument, apprendre et changer ses pratiques, ou se convaincre qu'il est si unique, important et intelligent qu'il peut aller a l'encontre de toutes les pratiques de l'industrie ces 15 dernières années.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
      - [^] # Re: Mon expérience à deux balles
        
        Posté par barmic le 17 juin 2018 à 16:46. Évalué à 2.
        
        Par contre… Vous décrivez toujours vos dépendances entre fichier dans l'outil de build ?!
        Quand est-ce qu'on verra un compilateur C/C++ se charger de ça ? (prendre un ou plusieurs dossier et compiler tous les fichiers .o nécessaire en reconstruisant l'arbre de dépendances qui va bien)
        
        Ce sera tellement performant et permettra de simplifier les outils de builds. Le compilateur sait lire la syntaxe du langage, il sait dont déduire les dépendances.
        
        [^] # Re: Mon expérience à deux balles
        
        Posté par claudex le 17 juin 2018 à 17:22. Évalué à 3.
        
        Je ne fais pas de C++, ce n'est qu'un exemple inventé dans le contexte.
        
        « 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: Mon expérience à deux balles
        
        Posté par pulkomandy (site web personnel, Mastodon) le 17 juin 2018 à 17:31. Évalué à 4.
        
        gcc sait le faire, avec la famille d'options qui commencent par -M. Je crois qu'il peut même te générer un Makefile.
        
        C'est ce que cmake utilise pour gérer les dépendances, par exemple.
- [^] # Re: Mon expérience à deux balles
  
  Posté par barmic le 15 juin 2018 à 14:12. Évalué à 1. Dernière modification le 15 juin 2018 à 14:16.
  
  Gradle est le plus intéressant des 3 a mon avis. Déjà il a abandonner le XML au profit du JSON.
  
  C'est du groovy pas du tout du json. Par contre il a un très gros défaut c'est que la syntaxe n'est pas complètement validée et on se retrouve avec des erreurs au runtime (runtime du build). C'est pour ça qu'ils regardent pour utilise kotlin à la place, mais ça fait un an et demi et c'est toujours pas vraiment la méthode conseillée.
# qbs

Posté par Fabien PRORIOL le 15 juin 2018 à 10:07. Évalué à 2.

Perso, j'utilise aussi CMake; parfois avec Ninja sur les gros projets…
Par contre, j'ai pas encore eu le temps de trop tester, mais je pense que QBS peut être un projet intéressant a surveiller…
Le but est de se passer de Make, QBS lance lui même GCC au lieu de CMake -> Makefile -> GCC
De plus, sa syntaxe déclarative a la QML devrait permettre une meilleur intégration dans les IDE, et cerise sur le gâteau, si on a besoin de faire des truc tordus, le javascript peut être utilisé directement dans le qbs…
Y'a une bonne équipe de développeur derrière (projet Qt, a la prétention de remplacer QMake/CMake pour Qt 6)

A suivre
# Ant > Maven > Gradle

Posté par Mimoza le 15 juin 2018 à 10:39. Évalué à 4.

Historiquement c'est dans cet ordre qu'il faut les présenter : Ant > Maven > Gradle

Ant, comme tu le dit, est une sorte de Makefiles en XML et très orienté pour les build Java, mais pas que, normalement. De base il n'a pas de gestion de dépendance, c'est le plug-in Ivy qui le fait pour lui. Un de ses gros défaut (outre la syntaxe XML) est que ses tâches/cibles sont très verbeuses a écrire et difficilement mutualisable/réutilisable. Il faut sans cesse réinventer la roue, mais permet de personnaliser finement ses script.

Maven est l'outil le plus populaire/répandu actuellement, surtout grâce a son écosystème très étendu. Tu as un plug-in pour quasiment tout ce que tu souhaite. Là encore les fichiers (pom.xml) sont en … XML. Il essaye de palier au défaut de Ant en ne permettant pas de scripter dans ses fichiers de description. Il faut obligatoirement passer par un plug-in, donc très grosse réutilisabilité du code … normalement. Sa gestion des dépendance est assez efficace et propose quelques outils pour résoudre les conflits

Gradle est le plus intéressant des 3 a mon avis. Déjà il a abandonner le XML au profit du JSON. Il ne profite malheureusement pas d'un écosystème aussi étendue que Maven, mais permet l'écriture de scipt en Groovy dans les fichiers projets en plus de l'utilisation de tâche/plug-in. Groovy n'est peut être pas le meilleur choix, mais vue que la population qui l'utilise est Javaïste en majorité le choix de ce langage de scripting est logique. Un peu le meilleur des 2 outils précédents a mon avis. Bien sûr gère les dépendance de manière assez efficace. Enfin point de vu perf il a un mode résident et compilation incrémentale des plus intéressant (https://guides.gradle.org/performance/).
# maven et gradle

Posté par barmic le 15 juin 2018 à 10:42. Évalué à 4.

Pour maven :

C'est un outil qui a l'air très professionnel. Ah mais attend… c'est pour ça qu'on comprend rien au descriptif ! La première version date de 2004 et c'est donc tout naturellement que le langage le plus populaire du début du siècle a été choisi pour les scripts de build, je parle bien sûr du 🎉 XML 🎉.

C'est marrant de reprocher à tous les outils de juste chercher à être rapide plutôt que fonctionnelle et de se foutre de la gueule de celui qui est juste fonctionnel ;)

Pour gradle :

Les trucs qui me fatiguent le plus avec Gradle sont d'abord le temps de compilation. La compilation du projet Java de nos jeux, une partie qui contient pourtant peu de code, prend quasiment une minute.

Je suis vraiment surpris, gradle est vraiment très efficace. Il faut par contre d'une part laisser le deamon se lancer et d'autre part ne pas utiliser de clean à tout bout de champ. Il prend très bien en compte les rebuilds (une étape de build est identifiée par les fichiers sources, la configuration de l'outil de build et éventuellement des éléments de ton système (l'architecture matériel par exemple).
- [^] # Re: maven et gradle
  
  Posté par Julien Jorge (site web personnel) le 15 juin 2018 à 11:17. Évalué à 4.
  
  Pour être tout à fait honnête je pense que le temps de build un peu long avec Gradle est surtout lié au fait que la cible soit Android. Il y a des étapes d'empaquetage (assets, apk) et de fusion de dex qui sont bien coûteuses et que l'on ne trouve pas dans un projet Java classique.
  - [^] # Re: maven et gradle
    
    Posté par SpaceFox (site web personnel, Mastodon) le 15 juin 2018 à 11:26. Évalué à 5.
    
    Mon expérience confirme ça. J'ajoute qu'Android utilise assez massivement des étapes supplémentaires type génération de code ou obscurcissement/optimisation du code. Résultat : c'est plus long de compiler un projet gros-mais-raisonnable en Android que de générer un .war démesurément immense (parce qu'il embarque n'importe quoi) en Java EE, les deux projets étant sous Gradle – alors que le PC de développement Android est plus puissant.
    
    Autre effet kiss cool : avec les étapes supplémentaires, un build Android d'un gros projet devient très rapidement extrêmement couteux en CPU et en RAM, puis en accès disque. D'ailleurs, un build Android sous Linux est bien plus rapide (facteur > 2 il y a environ deux ans sur un bon PC avec SSD) que le même sur le même matériel mais sous Windows – à tel point que la VM Linux dans un hôte Windows builde plus rapidement que Windows natif !
    
    La connaissance libre : https://zestedesavoir.com
# Build2

Posté par rewind (Mastodon) le 15 juin 2018 à 11:05. Évalué à 4.

Tu peux ajouter build2 à ta liste.
# Une défense des autotools

Posté par gouttegd le 15 juin 2018 à 13:59. Évalué à 10.
Je sais que beaucoup de gens aiment bien dire pis que pendre des autootools, mais j’aimerais quand même les défendre un peu, à la fois du point de vue de l’utilisateur (ie, celui qui veut compiler et installer un programme utilisant les autotools) et du point de vue du développeur (celui qui utilise les autotools pour gérer son projet).

Du point de vue de l’utilisateur, d’abord un peu de contexte. J’utilise Slackware, qui comme vous le savez peut-être est fournie avec assez peu de logiciels, de sorte qu’il m’arrive fréquemment de compiler moi-même les programmes que j’utilise (certainement plus souvent qu’un utilisateur de Debian ou Fedora par exemple). À titre indicatif, sur les 1534 paquets installés présentement sur mon système, 387 (25%) sont étrangers à la distribution et ont été compilés par mes soins. Une conséquence de ça, c’est que je suis pas mal confronté aux systèmes de build (non pas que ça me fasse grand plaisir, mais quand on choisit Slackware on sait à quoi s’attendre).

Encore un peu de contexte, avec quelques chiffres : sur les 387 paquets que j’ai construit moi-même et que j’utilise actuellement (je ne compte pas les paquets que j’ai construit par le passé mais que je n’utilise plus), j’enlève 149 paquets pour des modules Python qui ne sont pas vraiment pertinents ici (ils se construisent tous de la même manière, python setup.py build — et bon sang comme c’est agréable). Reste 238 paquets non-Python qui se répartissent ainsi :
- 173 utilisant les autotools (73%) ;
- 22 utilisant un « simple » (ou moins simple) Makefile (9%) ;
- 19 utilisant CMake (8%) ;
- 9 utilisant Waf (4%) ;
- 9 utilisant QMake (4%) ;
- 3 utilisant un système maison (1%) ;
- 2 utilisant Meson (1%) ;
- 1 utilisant Ant (< 1%).
Et bien, pour moi, le bilan est sans appel : je préfère largement construire un paquet pour un projet utilisant les autotools. Presque tous les autres systèmes m’ont posé des casses-têtes que je n’ai jamais eu avec les autotools qui sont pourtant beaucoup plus fréquents.

Pêle-mêle, quelques trucs qui m’irritent presque chaque fois que je dois compiler un projet sans les autotools :
- Pas toujours d’option standard pour indiquer où placer les bibliothèques. J’ai toujours besoin d’une option de ce genre, parce que Slackware a choisi, pour sa version 64 bits, d’installer les bibliothèques dans /usr/lib64 au lieu de /usr/lib. Oui, c’est un choix qui va à l’encontre de la plupart des autres distributions, mais il n’empêche : le système de build est supposé permettre de s’adapter au système cible. S’il ne le permet pas, c’est un système de build de merde, dont je maudis les auteurs sur cinq générations.
Mention très défavorable à CMake, qui est quand même là depuis suffisamment longtemps pour qu’on puisse se dire qu’une telle option devrait être disponible en standard, mais non : avec CMake, chaque projet fait sa propre sauce. Parfois il y a une option LIB_SUFFIX, parfois une option INSTALL_LIB_DIR, parfois une option WANT_LIB64, parfois une option MULTIARCH_SUFFIX — j’adore parcourir les CMakeLists.txt à la recherche de la bonne option, c’est ma joie —, et parfois… il n’y a pas d’option : le chemin d’installation des bibliothèques est codé en dur et il faut aller le modifier soi-même dans le CMakeLists.
- Pas toujours d’option standard pour indiquer où placer les pages de manuel ou d’info. Idem que ci-dessus. Avec les autools, c’est --mandir et --infodir. Avec CMake, parfois c’est MANDIR, le plus souvent c’est rien du tout, encore une fois il faut changer le chemin codé en dur dans le CMakeLists (ou aller déplacer les pages de manuel dans le bon dossier après installation).
- Plus généralement, le fait que tous ces projets ne sont pas fichus de s’arranger pour avoir une interface raisonnablement commune. Pensez ce que vous voulez des autotools, mais ils sont là depuis plus de vingt ans et les développeurs y sont habitués. Si vous voulez coder le nouveau build system du futur, au moins essayez de coller autant que possible à la syntaxe du classique configure (un bon point à Waf et Meson sur ce point — CMake, va te jeter dans les flammes de la Montagne du Destin où tu as été forgé, merci).
- Le simple fait de devoir installer yet-another-build-system juste pour pouvoir compiler un logiciel. Les autotools ont ceci de pratique qu’ils ne doivent être installés que sur la machine du développeur. Côté utilisateur, un shell (même pas besoin que ce soit GNU Bash) et un make (même pas besoin que ce soit GNU Make) suffisent. Mention spéciale aux projets qui ne se compilent qu’avec la dernière version de leur build-system, celle qui est sortie avant-hier.
Du point de vue du développeur maintenant : les autotools ne sont certes pas parfait (notamment, ils sont lents, c’est indéniable), mais il y a quand même quelques petites (ou pas si petites) choses que j’apprécie, comme :
- le support de la compilation croisée, y compris vers Windows (--build=x86_64-slackware-linux --host=i686-mingw32) ;
- make distcheck, pour non seulement générer une tarball mais vérifier automatiquement qu’elle est complète et autosuffisante ;
- le support automatique de toutes les options qu’on attend d’un système de build conforme aux GNU Coding Standards (--prefix, --libdir, --mandir, plus généralement tous les --machinsdir, --disable-static, --program-prefix, etc.) ;
- la prise en charge de gettext (alors là, je suis d’accord, c’est géré de façon très moche — mais au moins c’est géré, ce qui n’est pas le cas avec tous les autres systèmes…).
Les autotools ont leur défaut, certes. Mais demandez-vous aussi pourquoi ils sont encore massivement utilisés.

Pour ma part, franchement, je n’ai vu passer aucun système de build que je puisse considérer comme un successeur crédible aux autotools (non, CMake n’est pas un successeur crédible, voir ci-dessus), à part Meson récemment qui semble prometteur.
- [^] # Re: Une défense des autotools
  
  Posté par Renault (site web personnel) le 15 juin 2018 à 14:43. Évalué à 6.
  
  le support de la compilation croisée, y compris vers Windows (--build=x86_64-slackware-linux --host=i686-mingw32) ;
  
  Étant développeur système embarqué, ayant touché pas mal à Yocto et buildroot, il est claire qu'autotools est clairement le plus simple pour cet usage. Ajouter un nouveau paquet autotools est d'une très grande simplicité.
- [^] # Re: Une défense des autotools
  
  Posté par David Demelier (site web personnel) le 15 juin 2018 à 16:09. Évalué à 3.
  
  Sauf que autotools est beaucoup trop Linux only. Oublie les projets autotools sur Windows.
  
  git is great because linus did it, mercurial is better because he didn't
  - [^] # Re: Une défense des autotools
    
    Posté par gouttegd le 15 juin 2018 à 16:28. Évalué à 7.
    
    Sauf que autotools est beaucoup trop Linux only.
    
    Alors là c’est n’importe quoi. Les autotools fonctionnent sur n’importe quel système qui a un Bourne shell (même pas un shell POSIX, non, un Bourne shell des années 80 fait l’affaire) et un Make. Il n’y a aucune dépendance spécifique à Linux ni au système GNU de manière générale.
    
    Merde, une des principales raisons d’être des autotools a toujours été de pouvoir compiler les programmes du projet GNU sur toutes les variantes d’UNIX. D’ailleurs c’est peut-être même un des principaux reproches qu’on pourrait leur faire aujourd’hui : ils ont dans une large mesure été conçus pour répondre à des problématiques du passé, datant de l’époque des « UNIX wars » et des compatibilités hasardeuses. Qui a besoin aujourd’hui de compiler des programmes pour Tektronix UTekV, Amdahl UTS ou Motorola System V/88 ?
    
    Mais leur reprocher d’être Linux-centrique, même pour un vendredi c’est trop gros.
    
    Oublie les projets autotools sur Windows.
    
    C’est vrai, mais il est au moins possible de cross-compiler des programmes pour Windows depuis un système où les autotools sont disponibles. Pour un projet dont les développeurs sont sous GNU/Linux ou assimilés et qui veut fournir des exécutables Windows, c’est une option viable.
    - [^] # Re: Une défense des autotools
      
      Posté par liberforce (site web personnel) le 15 juin 2018 à 18:15. Évalué à 2. Dernière modification le 15 juin 2018 à 18:17.
      Sauf que autotools est beaucoup trop Linux only.
      
      Alors là c’est n’importe quoi.
      
      Je ne suis pas d'accord. Autotools sous Windows, ça lance tellement de process que ça rajoute un overhead énorme par rapport à ce que cela fait. Dans le lien donné plus haut sur la migration de GStreamer à Meson, le développeur explique qu'ils ont gagné énormément de temps sur le build Windows (× 10) par rapport à autotools, sans doute pour cette raison là. Bien sûr, sur des gros projets le temps de build sera largement dominé par le compilateur, mais sur des projets plus petits, la lenteur du build system peut avoir un impact non négligeable.
      
      Ensuite autotools c'est aussi différentes versions de autobidule et autotruc à installer en parallèle parce que non compatibles. Alors oui tu peux faire de la cross-compilation de Linux vers Windows, mais dans ce cas il ne faut s'offusquer qu'on dise que c'est trop "Linux only" (par opposition à Windows, pas par rapport aux autres UNIX).
      
      Ensuite, tu ne pourras à ma connaissance pas builder avec le compilateur de Visual Studio si tu es sous Windows. Si on te donne des bibliothèques proprios pour lesquelles on ne te donne que les binaires et que tu dois t'intégrer avec, tu fais quoi ? Idem pour les symboles de debug différents entre gcc et Visual Studio qui font que tu peux avoir envie d'utiliser un compilateur unique pour être capable de déboguer le bouzin.
      
      Enfin, autotools ne fonctionne qu'avec Make, avec tous les reproches qu'on peut faire sur Make, là où CMake et Meson sont compatibles ninja. Ninja a pour objectif de fournir un format très simple et hautement parallélisable, parce que ce sont les besoins de notre l'époque. De son côté, GNU Make va par défaut chercher des fichiers de logiciels de version obsolètes RCS et SCCS parce qu'il a été développé à une autre époque et qu'il a forcément du "bagage". "bagage" qui n'a pas été jeté parce que la compatibilité à tout prix empêche aussi l'évolution. GNU Make est un très bon logiciel, et tout à fait honorable, mais plus forcément une solution optimale au problème.
      
      CMake et Meson (et bien d'autres sans doute), ça produit des projets pour Visual Studio et Xcode, et ça marche aussi sous Linux. Autotools n'a à ma connaissance pas apporté de solutions à ces problèmes (mais je serais ravi qu'on me pointe des solutions qui seraient passées sous mon radar).
      
      Pour finir, voilà deux liens de l'auteur de Meson sur les reproches qu'il a fait à autotools et CMake, ainsi que des anti patterns Meson (parce qu'aucun outil n'est parfais, les soucis sont juste différents):
      
      http://voices.canonical.com/jussi.pakkanen/2011/09/13/autotools/
      
      http://voices.canonical.com/jussi.pakkanen/2013/03/26/a-list-of-common-cmake-antipatterns/
      
      http://nibblestew.blogspot.com/2017/05/a-list-of-common-meson-antipatterns.html
- [^] # Re: Une défense des autotools
  
  Posté par jyes le 15 juin 2018 à 21:44. Évalué à 4.
  
  De ma toute petite expérience des systèmes de construction côté développeur, autotools est aussi celui qui se met le moins en travers de ton chemin quand tu as le malheur de ne pas être cool aux yeux des développeurs de l’outils. Dans mon cas, mon plus gros projet est en Fortran.
  
  Malgré un vernis publicitaire pour certains, aucun système de build ne gère correctement les dépendances dans ce langage, et encore moins si vous avez l’idée saugrenue de ne pas écrire un script de construction spécifique pour chaque compilateur.
  
  Au final, les autotools ne font pas tout, mais déjà plus que leurs concurrents, et surtout, c’est très facile de les ajuster aux cas qu’ils ne gèrent pas directement. Gestion manuelle des dépendances ? Tu as juste à te débrouiller pour fournir un Makefile.am correct. Détection de lib obscure qui fait pas classe en soirée ? Facile d’écrire ses scripts de tests.
  
  Du coup, le seul système de compilation que j’ai réussi à utiliser est les autotools. Je m’arrache encore un peu les cheveux de temps en temps mais au final, je n’ai toujours pas perdu autant de temps dans le manuel des autotools après 5 ans sur le même projet, que le temps que j’ai passé dans celui de CMake pour écrire un CMakeList.txt minimaliste qui parvient tout juste à compiler mon projet. Alors que les autotools font compiler mon code avec plusieurs compilateurs, sur des machines très différentes et des systèmes d’exploitations variés, sur lesquelles j’ai rarement les droits d’administration.
  - [^] # Re: Une défense des autotools
    
    Posté par pulkomandy (site web personnel, Mastodon) le 17 juin 2018 à 17:47. Évalué à 2.
    
    Je dirais bien d'aller voir du côté de Jam (la version de Perforce, celle de Boost, celle de Freetype ou celle de Haiku), si c'était pas un outil non maintenu avec 3 forks incompatible… C'est dommage, parce que c'est un bon remplacement de make, avec la possibilité de définir des règles génériques, qui conviendrait pas mal pour ce genre d'usage.
- [^] # Re: Une défense des autotools
  
  Posté par G.bleu (site web personnel) le 17 juin 2018 à 10:34. Évalué à 4.
  
  Perso mon expérience des autotools ça a été de créer un petit projet avec (https://github.com/touilleMan/mpa_robot).
  
  Le truc fait grosso modo 1000 lignes de C++, mon projet sur Github est indiqué comme étant composé à 95.5% de shell…
  On a 13 fichiers à la racine du projet dédié aux autotools, plus 2 fichiers pour chaque répertoire (Makefile.in et Makefile.am)
  
  J'imagine qu'on peut améliorer ça, mais déjà pour en arriver là ça m'avais pris plusieurs heures de travaille (j'avais à cœur d'apprendre à utiliser les autotools).
  
  Le clou dans le cercueil à été 6 mois plus tard quand j'ai voulu ajouter un nouveau fichier C++ au build. Après plusieurs heures passées pour re-comprendre le bouzin, tenter de réinstaller les outils (oui mais versions incompatibles et rien pour te l'indiquer clairement…), de regénérer les fichiers (comment on met à jour un .am à partir d'un .in ? si ça crash à cause de la version de l'outil, de mon script ou bien de ma commande ? etc.) j'ai fini par abandonner.
  
  Sérieusement les éditeurs de jeux vidéos devraient mettre Autotools plutôt que SecuRom pour protéger leurs jeux des modifications des hackers.
  - [^] # Re: Une défense des autotools
    
    Posté par gouttegd le 17 juin 2018 à 11:05. Évalué à 6.
    
    Le truc fait grosso modo 1000 lignes de C++, mon projet sur Github est indiqué comme étant composé à 95.5% de shell…
    On a 13 fichiers à la racine du projet dédié aux autotools, plus 2 fichiers pour chaque répertoire (Makefile.in et Makefile.am)
    
    Rien ne t’oblige à committer les fichiers générés, il est d’ailleurs généralement recommandé de ne pas le faire…
    
    Perso, pour tous mes projets j’ai juste un configure.ac et un Makefile.am à la racine, plus un Makefile.am dans chaque dossier source. Tout le reste est généré et n’a pas besoin d’être committé.
    
    Le clou dans le cercueil à été 6 mois plus tard quand j'ai voulu ajouter un nouveau fichier C++ au build. Après plusieurs heures passées pour re-comprendre le bouzin
    
    Des heures pour trouver qu’il faut ajouter le nom du fichier à la variable monprogramme_SOURCES dans le fichier Makefile.am ?
    
    comment on met à jour un .am à partir d'un .in
    
    On ne le fait pas, c’est le contraire : le Makefile.in est généré à partir du Makefile.am. C’est sûr que si tu as voulu ajouter ton nouveau fichier dans le Makefile.in, ça allait beaucoup moins bien marcher…
    
    Sérieusement les éditeurs de jeux vidéos devraient mettre Autotools plutôt que SecuRom pour protéger leurs jeux des modifications des hackers.
    
    Ça les protégera seulement des Kevin qui ne savent pas lire des docs, certainement pas des hackers…
    
    Sérieusement, tu dis avoir eu à cœur d’apprendre les Autotools, mais ton expérience, soit est une caricature trollesque, soit est typique de celui qui veut utiliser les autotools sans rien comprendre de ce qu’il fait. (C’est très fréquent : beaucoup d’utilisateurs des Autotools se contentent de recopier ce qu’ils voient dans d’autres projets sans même jamais lire la moindre documentation ; ça ne peut que mal se terminer.)
    
    Les Autotools ne sont pas les outils les plus faciles à utiliser, c’est un fait et c’est une critique tout-à-fait valable. Mais là, le problème est entre la chaise et le clavier.
    - [^] # Re: Une défense des autotools
      
      Posté par G.bleu (site web personnel) le 18 juin 2018 à 10:23. Évalué à 0.
      
      Des heures pour trouver qu’il faut ajouter le nom du fichier à la variable monprogramme_SOURCES dans le fichier Makefile.am ?
      
      Non, des heures pour se remémorer les commandes et le fonctionnement du truc, pour chercher la doc sur internet et surtout pour comprendre que la version d'autotools de ma Gentoo d'il y a 6mois était incompatible avec celle de mon Ubuntu. Débugger des scripts de plusieurs milliers de lignes c'est tellement facile.
      
      Rien ne t’oblige à committer les fichiers générés, il est d’ailleurs généralement recommandé de ne pas le faire…
      
      Tout à fait, comme ça non seulement je ne pouvais plus rajouter de fichiers mais en plus je pouvais plus non plus générer le build ;)
      
      Sérieusement, tu dis avoir eu à cœur d’apprendre les Autotools, mais ton expérience, soit est une caricature trollesque, soit est typique de celui qui veut utiliser les autotools sans rien comprendre de ce qu’il fait.
      
      Sérieusement, j'ai publié mon expérience, j'ai pris la peine de mettre un lien vers le projet en question donc me traiter de troll et insinuer que je suis incompétent c'est franchement un gros manque de respect de ta part.
      
      Les Autotools ne sont pas les outils les plus faciles à utiliser, c’est un fait et c’est une critique tout-à-fait valable.
      
      Merci, donc au final on arrive à la même conclusion ;-)
- [^] # Re: Une défense des autotools
  
  Posté par pulkomandy (site web personnel, Mastodon) le 17 juin 2018 à 17:45. Évalué à 4.
  
  Alors je dois prendre la défense de CMake sur ce point: il y a bien une méthode standard pour la prise en charge des dossiers d'installation, c'est GNUInstallDirs. Le problème, c'est que c'est un ajout relativement récent (ça fait quelques années quand même) et que beaucoup de projets ne l'utilisent pas et codent tout en dur. Et quand c'est utilisé, ça marche tout aussi bien que les autotools (et je dis ça en ayant packagé pas mal de choses pour Haiku, qui fait des trucs bien plus tordus que slackware en terme de chemin standardisés pour les bibliothèques, les manpages, …)
  
  Donc ce n'est pas vraiment la faute de l'outil, mais plutôt d'une mauvaise utilisation (bon et aussi du fait que les dévs de CMake ont pendant quelques temps "oublié" de documenter GNUInstallDirs…
  
  Il y a aussi toute la gestion du packaging (avec CPack) qui de mon expérience, fonctionne plutôt bien, pour générer des tarballs. Et il y a le support de la compilation croisée.
# SBT

Posté par flan (site web personnel) le 15 juin 2018 à 14:03. Évalué à 5.

Il manque Simple Build Tool dans ce panorama, qui a été renommé en Scala Build Tool. Bon, ok, ce n'est pas forcément une mauvaise idée de l'oublier, après tout.
J'ai eu le malheur d'utiliser SBT il y a quelques années. Bon, il fallait 2 min montre en main pour le lancer (je parle bien du temps de chargement de SBT avec un fichier .sbt de 20 ou 30 lignes, hein, pas de l'exécution elle-même), certes sur une machine de 2010.
Il réussissait aussi à mourir par manque de RAM (seulement 4 Go de dispo, j'avoue) lors du packaging d'un projet de 10 Mo (concrètement, il s'agit juste de copier quelques fichiers dans un zip, rien de plus).
Bien sûr, il avait aussi besoin de télécharger internet à chaque build (même s'il l'avait téléchargé 5 min avant). Pas pratique quand on n'a pas internet (ce qui est souvent mon cas)…

Ah, et comme les développeurs se sont dit que les classiques points-virgules pour séparer les instructions coûtaient vraiment cher, ils se sont dit qu'il valait mieux les remplacer par une ligne vide, histoire de doubler l'espace vertical occupé à l'écran.

Spark donne (donnait ?) un bon exemple de gestion de versions avec sbt : un fichier .sbt était fourni pour Scala 2.10 mais permettait également de compiler en 2.11, en cherchant d'abord tous les fichiers pom.xml dans le projet pour y appliquer un sed s/2.10/2.11/g (méthode fiable et propre s'il en est).
# Par Crom, il faut un maven pour C++ !

Posté par devnewton 🍺 (site web personnel) le 15 juin 2018 à 14:33. Évalué à 2.

Aujourd'hui un système de construction doit absolument gérer les dépendances et le packaging en plus de la compilation. Pour tous les bons langages, il y a un outil unique ou des outils intégrés entre eux pour ces trois fonctions: Maven pour Java/Scala/Kotlin/… ou brunch.io pour HTML/CSS/Javascript/Typescript.

Ce qui s'en rapproche le plus pour C++, c'est conan, mais ça n'a pas l'air très simple.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
- [^] # Re: Par Crom, il faut un maven pour C++ !
  
  Posté par liberforce (site web personnel) le 15 juin 2018 à 15:02. Évalué à 2. Dernière modification le 15 juin 2018 à 15:04.
  
  Je fais du conan depuis quelques temps, c'est quand même pas mal. Il faut un peu de temps pour déchiffrer leur doc, et j'aurais aimé pouvoir me plonger dedans et faire des retours avant leur version 1.0. Aujourd'hui beaucoup de chose ne peuvent plus changer pour garder la rétro compatibilité, mais ça reste quand même une solution de packaging multi-plateforme que je trouve assez viable et aboutie. La doc parle beaucoup de CMake mais ce n'est pas lié à un unique build system et il y a plusieurs build helpers gérés. Meson est d'ailleurs plus pratique à ce niveau, car le build helper génère juste le fichier .pc utile à pkg-config, alors que les recettes conan utilisant CMake doivent patcher le CMakeLists.txt à la volée si tu veux continuer à pouvoir builder en CMake pur sans conan (chercher replace_in_file dans le "Getting Started").
  - [^] # Re: Par Crom, il faut un maven pour C++ !
    
    Posté par Julien Jorge (site web personnel) le 15 juin 2018 à 22:15. Évalué à 2.
    
    Est-ce qu'il y a beaucoup de libs déjà packagées avec Conan ? Par exemple j'ai cherché un jsoncpp compilé pour Linux, pour faire simple, je ne l'ai pas trouvé. Est-ce qu'il y a des libs précompilées pour Android, iOS et OSX ?
    
    Nous l'avions considéré fut un temps mais au final nous sommes partis sur un autre outil car nous avions besoin de gérer des dépendances plus variées comme des frameworks de divers fournisseurs de services ainsi que le SDK et le NDK d'Android.
    - [^] # Re: Par Crom, il faut un maven pour C++ !
      
      Posté par liberforce (site web personnel) le 19 juin 2018 à 10:50. Évalué à 3. Dernière modification le 19 juin 2018 à 10:52.
      $ conan search jsoncpp -r all Existing package recipes: Remote 'conan-center': jsoncpp/1.0.0@theirix/stable jsoncpp/1.8.4@theirix/stable jsoncpp/1.8.4@theirix/testing
      
      Je ne connais en revanche pas la situation des libs précompilées pour Android, iOS et OSX, mais un conan install jsoncpp/1.8.4@theirix/stable --build=missing sur les plateformes en question devrait te permettre de les builder. Une fois fait, c'est disponible dans ton dépôt local. Il faut toutefois que celui qui a écrit la recette ait prévu un minimum la gestion ces plateformes, si ce n'est pas le cas, tu risques d'avoir quelques bugs et de devoir patcher la recette.
- [^] # Re: Par Crom, il faut un maven pour C++ !
  
  Posté par David Demelier (site web personnel) le 15 juin 2018 à 16:03. Évalué à 4.
  
  Par pitié non, je désespère quand je dois utiliser quelque chose en node.js qui rapatrie le monde entier à chaque installation. S'il y a bien une chose qui me déplaît dans ces façons de faire c'est qu'après avoir téléchargé ton dépôt, tu dois encore télécharger des dizaines d'autre dépôt pour pouvoir construire ton application. Avec C et C++ on a la chance de les avoir déjà dans le système ce qui permet entre autre de ne pas gaspiller du temps de compilation inutile et de la place.
  
  git is great because linus did it, mercurial is better because he didn't
  - [^] # Re: Par Crom, il faut un maven pour C++ !
    
    Posté par devnewton 🍺 (site web personnel) le 15 juin 2018 à 16:46. Évalué à 6.
    
    Avec C et C++ on a la chance de les avoir déjà dans le système ce qui permet entre autre de ne pas gaspiller du temps de compilation inutile et de la place
    
    Et quand les OS cibles n'ont pas les paquets (ou seulement dans une version obsolète), tu pleures très fort.
    
    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
    - [^] # Re: Par Crom, il faut un maven pour C++ !
      
      Posté par Firwen (site web personnel) le 17 juin 2018 à 16:48. Évalué à 2.
      
      Et quand les OS cibles n'ont pas les paquets (ou seulement dans une version obsolète), tu pleures très fort.
      
      Ben ce que tu as besoin c'est alors d'un package manager cross platform. Du genre Nix ou Spack.
      
      Et non d'un enième build système langage spécifique qui se prend pour un package manager, en faisant mal le job, et en chiant sur tout ce qui n'est pas directement son langage.
  - [^] # Re: Par Crom, il faut un maven pour C++ !
    
    Posté par barmic le 16 juin 2018 à 01:50. Évalué à 1.
    
    Euh ? Tu va les télécharger quoi qu'il arrive. Il n'y a pas de raison de penser que ton système est le système cible et même comme ça, le support des versions précédente de ton logiciel ou le test de la version suivante (ou d'options de compilation différentes) d'une bibliothèque t'oblige à faire des installations non système.
    - [^] # Re: Par Crom, il faut un maven pour C++ !
      
      Posté par Firwen (site web personnel) le 17 juin 2018 à 16:45. Évalué à 2.
      
      Euh ? Tu va les télécharger quoi qu'il arrive
      
      Justement non. Et C'est une des raisons qui me font détester ces build systèmes qui se prennent pour des packages managers.
      
      Il y a beaucoup de système dans ce monde qui n'ont pas accès et n'auront jamais accès à internet pour de très bonne raisons. ( sécurité, banque, réseau spécialisé, super-calculateurs … )
      
      Pouvoir installer un soft juste en utilisant des dépendances locales spécifiées à la main est un pré-requirement de tout bon build système.
      
      Pour ceux qui en doutent, je vous conseille fortement de voir le talk "How to make life of package manager miserables" de K Hoste de la dernière FOSDEM.
      
      https://mirror.as35701.net/video.fosdem.org/2018/K.3.201/how_to_make_package_managers_cry.webm
      - [^] # Re: Par Crom, il faut un maven pour C++ !
        
        Posté par barmic le 17 juin 2018 à 17:47. Évalué à 1.
        
        Justement non.
        
        Oui tu demande à apt de les télécharger. Bien. Maintenant comment tu fais pour avoir plusieurs versions de libc diférentes ? Comment tu fais pour tester la mise à jour de l'une de tes dépendance ? Comment tu fais pour expliquer à tes contributeurs la liste de tes dépendances qu'ils utilise nix, debian, redhat ou gentoo ? Comment tu t'assure que tes dépendances ont bien les bonnes options de compilation ?
        
        Tu parle de ton principe, mais tu n'explique pas comment dans la pratique tu fais ces choses vitales. La seule autre option c'est d'utiliser des choses comme lxc ou docker. C'est un peu gros comme truc et ça marche pas bien multi plateforme.
        
        [^] # Re: Par Crom, il faut un maven pour C++ !
        
        Posté par Firwen (site web personnel) le 17 juin 2018 à 20:14. Évalué à 1.
        
        Oui tu demande à apt de les télécharger. Bien. Maintenant comment tu fais pour avoir plusieurs versions de libc diférentes ?
        
        Tu as pas du comprendre ce que je dis.
        
        Sur beaucoup de systèmes HPC / Banque, il n'y a PAS d'internet. Ni APT, ni quoi que ce soit d'autre en accés directe. Les noeuds en eux même sont souvent diskless et proviennent d'image statique déployées et controlées par les sys admins.
        
        Tu as SSH et RIEN. Si tu veux déployer ton app, tu le fais toi même depuis les sources.
        
        [^] # Re: Par Crom, il faut un maven pour C++ !
        
        Posté par barmic le 17 juin 2018 à 20:32. Évalué à 3.
        
        Hein ? Tu build en prod ? On parle d'outil de build, non ? Si tu n'a pas de dépendance le fait d'utiliser un outil qui va télécharger des dépendances ne change rien (astuce: si tu ne liste aucune dépendances, il n'en télécharge pas !!!)
        
        Si tu parle vraiment de la partie build et pour prendre l'exemple qui revient à chaque fois qu'on parle de ce genre de choses. Maven n'a pas besoin d'internet. Il va par défaut aller chercher sur internet oui, mais il n'en a aucunement besoin. Il fournit juste des moyens standardisé de récupérer des bibliothèques. Il propose par défaut d'avoir un référentiel de ces dépendances. L'objectif étant d'essayer d'avoir des builds reproductibles. Mais tu peux parfaitement utiliser maven sans internet et même sans réseau.
        
        J'ai pas de doute qu'il y a des cas où ça marche vraiment pas, mais le fait qu'on ai maven/pip/cpa/gem/npm/… Montre que c'est un besoin que les gens ont. On peut se dire que la population de développeurs de tous ses langages sont en dehors des réalités, mais c'est quand même un peu prétentieux, tu ne crois pas ?
        
        [^] # Re: Par Crom, il faut un maven pour C++ !
        
        Posté par Firwen (site web personnel) le 17 juin 2018 à 22:03. Évalué à 5.
        
        Hein ? Tu build en prod ? On parle d'outil de build, non ? Si tu n'a pas de dépendance le fait d'utiliser un outil qui va télécharger des dépendances ne change rien (astuce: si tu ne liste aucune dépendances, il n'en télécharge pas !!!)
        
        Dans les workflows scientifiques (HPC) , la notion de "prod" est toute relative.
        
        Maven n'a pas besoin d'internet
        
        Maven peut être. Il a un paquet de build système qui se prennent pour des packages manager qui ne te laissent pas le choix
        
        le fait qu'on ai maven/pip/cpa/gem/npm/… Montre que c'est un besoin que les gens ont. On peut se dire que la population de développeurs de tous ses langages sont en dehors des réalités, mais c'est quand même un peu prétentieux, tu ne crois pas 
        
        Le fait qu'on ait maven/pip/cpa/gem/npm/conan/cabal/cargo/vcpkgs/gradle/goget illustre parfaitement le manque d'un package manager orienté développeur multi-language. Le résultat étant un zoo de tools redondant, souvent mal implémentés et faisant l'interopérabilité cross-language un cauchemar.
        
        [^] # Re: Par Crom, il faut un maven pour C++ !
        
        Posté par Guillawme (site web personnel, Mastodon) le 18 juin 2018 à 06:47. Évalué à 5.
        
        Le fait qu'on ait maven/pip/cpa/gem/npm/conan/cabal/cargo/vcpkgs/gradle/goget illustre parfaitement le manque d'un package manager orienté développeur multi-language.
        
        GNU Guix propose une abstraction au dessus de plusieurs « gestionnaires de paquets » spécifiques de différents langages. Je n’ai pas essayé, mais l’idée est intéressante. Ça n’enlève pas la dépendance à tous ces systèmes de construction, mais au moins ça ne demande d’interagir qu’avec un outil unique.
        
        https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-import.html
        
        [^] # Re: Par Crom, il faut un maven pour C++ !
        
        Posté par Firwen (site web personnel) le 18 juin 2018 à 11:03. Évalué à 2.
        
        GNU Guix propose une abstraction au dessus de plusieurs « gestionnaires de paquets » spécifiques de différents langages. Je n’ai pas essayé, mais l’idée est intéressante. Ça n’enlève pas la dépendance à tous ces systèmes de construction, mais au moins ça ne demande d’interagir qu’avec un outil unique.
        
        Et je pense que c'est une très bon pas dans la bonne direction. J'espère sincèrement qu'une solution du type GUIX/Nix, Spack ou EasyBuild prennent le dessus à l'avenir et mette un terme au zoo spécifique à chaque langage que nous avons actuellement.
        
        [^] # Re: Par Crom, il faut un maven pour C++ !
        
        Posté par David Demelier (site web personnel) le 17 juin 2018 à 20:19. Évalué à 5.
        
        Maintenant comment tu fais pour avoir plusieurs versions de libc diférentes
        
        C'est sûr que la libc change vraiment souvent… Sinon il y a des chroot/mock/containeur pour tester des build dans des environnement propres.
        
        Comment tu fais pour expliquer à tes contributeurs la liste de tes dépendances qu'ils utilise nix, debian, redhat ou gentoo ?
        
        Je leur dis « Boost, CMake, Qt5, libzip » enfin bref, le nom upstream de mon composant, à eux de trouver le nom dans leur gestionnaire de paquet (qui est souvent assez identique).
        
        Comment tu t'assure que tes dépendances ont bien les bonnes options de compilation ?
        
        La plupart des distributions compilent avec les valeur par défaut d'upstream, j'ai jamais eu de souci à ce niveau là. Puis les bibliothèque externes que j'ai utilisées jusque là n'ont pas d'options par défaut que les distibutions changent par ci par là.
        
        git is great because linus did it, mercurial is better because he didn't
        
        [^] # Re: Par Crom, il faut un maven pour C++ !
        
        Posté par barmic le 17 juin 2018 à 20:40. Évalué à 1.
        
        C'est sûr que la libc change vraiment souvent… Sinon il y a des chroot/mock/containeur pour tester des build dans des environnement propres.
        
        libc, parseur json, bibliothèques ssl, choisi ce que tu veux. Tu peux vouloir vérifier différentes libc aussi.
        
        Sinon il y a des chroot/mock/containeur pour tester des build dans des environnement propres.
        
        Aucun n'est véritablement portable, ça n'est pas très amusant d'utiliser docker sous windows et MacOS par exemple. Sur BSD je ne sais même pas comment s'est distribué.
        
        Je leur dis « Boost, CMake, Qt5, libzip » enfin bref, le nom upstream de mon composant, à eux de trouver le nom dans leur gestionnaire de paquet (qui est souvent assez identique).
        
        Ah oui, mais le mainteneur a une Debian stable, alors que moi je suis sur Fedora donc on utilise pas les même versions de bibliothèques… Ton logiciel doit passer les versions de bibliothèques en même temps que tu fais tes mises à jours d'OS ?
        
        Utiliser python avec virtualenv, c'est précisément faire un chroot ? Il va récupérer tes dépendances et s'assurer de ne te mettre à disposition que celles que tu as listée. Ça ne demande pas des manipulations trop compliquées et ne requière pas de droits root (pratique en environnement d'intégration).
        
        [^] # Re: Par Crom, il faut un maven pour C++ !
        
        Posté par David Demelier (site web personnel) le 18 juin 2018 à 10:55. Évalué à 3.
        
        Aucun n'est véritablement portable, ça n'est pas très amusant d'utiliser docker sous windows et MacOS par exemple. Sur BSD je ne sais même pas comment s'est distribué.
        
        Oui je sais bien, mais tu installes un sur ton serveur qui te plait et tu reste avec :-)
        
        Ah oui, mais le mainteneur a une Debian stable, alors que moi je suis sur Fedora donc on utilise pas les même versions de bibliothèques… Ton logiciel doit passer les versions de bibliothèques en même temps que tu fais tes mises à jours d'OS ?
        
        Dans mon cas, les bibliothèques que j'utilise ne sont pas du genre à casser la compatibilité d'une version mineure à l'autre (c'est d'ailleurs un critère de choix). J'utilise Boost principalement, Qt 5 ou parfois SDL 2. Et SDL 2 je sais que ça va rester pendant encore un moment (combien il y a d'années entre SDL 1 et SDL 2 ? tellement que les distributions fournissent les deux côte à côte) donc pour le moment je ne peux pas dire que j'ai eu des problèmes de compatibilité de version. Mon seul gros problème c'est la version des compilateurs sur les distributions car j'utilise déjà beaucoup de fonctionnalités du C++17 et je sais que ça va être compliqué pour les utilisateurs de debian, mais bon si je dois commencer à me restreindre pour des distributions je ne pourrai jamais coder en C++17. Il faut dire que la philosophie des développeur C ou C++ est largement différente de npm (pour ne citer que celui ci) justement parce que la retro compatibilité est bien plus forte et qu'on intègre plus rarement une bibliothèque externe directement dans son code alors que dans npm on peut se le permettre bien plus.
        
        git is great because linus did it, mercurial is better because he didn't
        
        [^] # Re: Par Crom, il faut un maven pour C++ !
        
        Posté par devnewton 🍺 (site web personnel) le 18 juin 2018 à 11:25. Évalué à 2.
        
        Il faut dire que la philosophie des développeur C ou C++ est largement différente de npm (pour ne citer que celui ci) justement parce que la retro compatibilité est bien plus forte et qu'on intègre plus rarement une bibliothèque externe directement dans son code alors que dans npm on peut se le permettre bien plus.
        
        C'est pas une philosophie: comme ajouter une dépendance demande un travail long et chiant, on préfère réinventer la roue :-)
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Par Crom, il faut un maven pour C++ !
        
        Posté par Firwen (site web personnel) le 18 juin 2018 à 11:54. Évalué à 6. Dernière modification le 18 juin 2018 à 11:54.
        
        C'est pas une philosophie: comme ajouter une dépendance demande un travail long et chiant, on préfère réinventer la roue :-)
        
        Désolé, Mais ça c'est une réflexion stupide.
        
        Ajouter une dépendance à un coût.
        
        Et malheureusement, un coût bien souvent sous évalué par les développeurs inexpérimentés ce qui amène à des situations de non-sense complet comme avec npm ou certains devs ajoute même une dépendance pour faire un hello world ( j'exagère à peine ).
        
        Ajouter une dépendance c'est lié la maintenabilité, donc le cout humain de son projet à une source externe ( souvent énormément de source externe récursivement) non contrôlée. Ce n'est JAMAIS une chose à prendre à la légère dans tout projet logiciel digne de ce nom.
        
        Ajouter une dépendance doit toujours être une décision basée sur un compromis entre perte de contrôle, et de maintenabilité d'un ajout externe et coût humain d'une ré-implémentation.
        
        Quand je vois des développeurs ajouter en dépendances des frameworks monstrueux de plusieurs centaines de milliers de lignes de code simplement pour utiliser 2-3 fonctions (utilitaires) de ces frameworks, c'est une absurdité, souvent du à l'inexpérience.
        
        [^] # Re: Par Crom, il faut un maven pour C++ !
        
        Posté par devnewton 🍺 (site web personnel) le 18 juin 2018 à 13:52. Évalué à 4.
        
        Ajouter une dépendance doit toujours être une décision basée sur un compromis entre perte de contrôle, et de maintenabilité d'un ajout externe et coût humain d'une ré-implémentation.
        
        Cette décision devrait seulement sur ces critères et pas zut si je veux utiliser cette lib, je vais devoir comprendre son système de build puis soit tuner l'ajouter à ma chaîne de compilation en statique soit la packager pour tous les OS cibles… mmh bon finalement je vais réinventer les algos qui m'intéressent et hop.
        
        Si pratiquement tous les langages modernes viennent avec un système de package, c'est qu'il y a des vrais besoins auquel les systèmes de paquets des OS ne répondront jamais.
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Par Crom, il faut un maven pour C++ !
        
        Posté par Firwen (site web personnel) le 18 juin 2018 à 14:49. Évalué à 5. Dernière modification le 18 juin 2018 à 14:50.
        
        Cette décision devrait seulement sur ces critères et pas zut si je veux utiliser cette lib, je vais devoir comprendre son système de build puis soit tuner l'ajouter à ma chaîne de compilation en statique soit la packager pour tous les OS cibles… mmh bon finalement je vais réinventer les algos qui m'intéressent et hop.
        
        Tout à fait d'accord sur ce point. Et oui les package manager des OS ne sont pas non plus des solutions à ces problèmes.
        
        Ceci dit, réimplémenter la roue dans chaque langage et shipper ses propres libs systèmes dans chaque pseudo-build système / package manager langage spécifique n'est pas non-plus une solution.
        
        Dans le monde idéal, je veux pouvoir déployer mon module C++ utilisé par un interpréteur python accompagné d'un petit service Java et d'un tool en Haskell sans avoir à :
        
        jongler entre le pip de python qui n'aime pas les libs binaires car c'est pas son job
        
        Conan de C++ qui n'aime pas JAVA car c'est pas son job
        
        Maven qui n'aime pas python parce qu'il a été marié à Java
        
        Et cabal de Haskell qui ne s'aime même pas lui même.
        
        Et j'ai volontairement laissé npm en dehors de l'histoire d'eviter le troll trop facile.
        
        [^] # Re: Par Crom, il faut un maven pour C++ !
        
        Posté par devnewton 🍺 (site web personnel) le 18 juin 2018 à 15:19. Évalué à 2.
        
        module C++ utilisé par un interpréteur python accompagné d'un petit service Java et d'un tool en Haskell
        
        Plus qu'à coder la toolchain multilang universelle!
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Par Crom, il faut un maven pour C++ !
        
        Posté par jyes le 18 juin 2018 à 16:03. Évalué à 2.
        
        Pour le build, c’est déjà assuré par les autotools, mais ils n’assurent pas l’installation des dépendances. Pour ça, l’avenir est plutôt du côté des Guix/Nix/Easybuild que des gestionnaires de paquets de chaque langage à la mode (quoique les premiers dépendront des seconds encore longtemps, vu le bordel qu’est la situation actuelle).
        
        [^] # Re: Par Crom, il faut un maven pour C++ !
        
        Posté par David Demelier (site web personnel) le 18 juin 2018 à 13:42. Évalué à 2. Dernière modification le 18 juin 2018 à 13:45.
        
        C'est pas une philosophie: comme ajouter une dépendance demande un travail long et chiant, on préfère réinventer la roue :-)
        
        Désolé mais je ne vois pas le rapport et je pense que tu n'as pas compris. Dans des projets node.js on utilise npm qui va installer les dépendances externes directement dans le dépôt de l'application alors que la tradition dans les applications C et C++ c'est d'utiliser celles installées par le gestionnaire de paquet de la distribution (donc de les garder externes).
        
        J'ai pourtant bien précisé « qu'on intègre plus rarement une bibliothèque externe directement dans son code ».
        
        git is great because linus did it, mercurial is better because he didn't
# scons

Posté par Troy McClure (site web personnel) le 15 juin 2018 à 14:44. Évalué à 3.

Ben moi je vote pour scons—sa lenteur est largement surestimée, en tout cas sur mes builds il ne pese pas trop lourd, et le fait d'être sûr que le build est correct, que les fichiers qui doivent être recompilés sont bien recompilés, compense largement les 3 secondes perdues au démarrage. Et le cache integré à scons fait aussi gagner beaucoup de temps. Sans parler du fait qu'on a un vrai langage de programmation pour définir les builds au lieu d'un truc batard et boiteux à la syntaxe merdique.
- [^] # Re: scons
  
  Posté par G.bleu (site web personnel) le 17 juin 2018 à 10:11. Évalué à 2.
  
  En effet j'ai découvert scons en contribuant à Godot (http://godotengine.org/) et c'est un système de build assez appréciable (en particulier le script via python qui amène pas mal de puissance et simplifie le débug grace à pdb).
  
  Au niveau de sa lenteur, c'était vrai il y a quelques années (les articles en parlant date de 2010…) mais ça a été corrigé depuis.
  Perso les soucis que j'ai eu avec été plus dû à la petite communauté (donc plus difficile de trouver des ressources fraîches sur le sujet) et surtout à sa politique de dépendances de compilation.
  Je m'explique: scons considère toujours qu'une cible de compilation (hors alias) est un chemin vers un fichier ou un répertoire. De là cibles de compilations pointant sur un répertoire/fichier parent sont considérées comme des dépendance.
  Ça peut sembler normal (je dois construire tout ce qu'il y a dans un répertoire avant de considérer celui-ci comme généré) mais ça très lourd quand on veut avoir une tache effectuant un traitement sur le répertoire une fois celui-ci généré :(
# CMake

Posté par David Demelier (site web personnel) le 15 juin 2018 à 16:01. Évalué à 1.

CMake, encore et toujours. Ça fait environ 10 ans que je l'utilise (déjà !). Il a ses défauts mais il fait tellement de chose et bien en plus il est supporté par un bon nombre d'IDE le rendant bien intégré. Pour ma part je l'utilise avec vim (vim-cmake) et Qt Creator.

git is great because linus did it, mercurial is better because he didn't
# Qt / QMake

Posté par AnthonyRabine (site web personnel) le 15 juin 2018 à 16:08. Évalué à 3.

Personnellement j'utilise Qt/QMake pour beaucoup de mes logiciels C++, même sans forcément utiliser les librairies Qt. J'ai déployé sur MacOS un logiciel très facilement et, astuce, Qt n'a besoin que des outils de développement en ligne de commande sur Mac, pas besoin d'installer tout XCode.

Le fichier projet est un .pro et le build QMake génère du Makefile bien propre pour la plateforme désirée. Deux clics pour ajouter un "Kit de Build" et un clic pour compiler. Dur dur.
# Bazel

Posté par Krunch (site web personnel) le 15 juin 2018 à 16:39. Évalué à 3.

Il y a des gens qui ont essayé Bazel ? https://bazel.build/ (j'utilise une variante proprio au boulot et ça marche fort bien)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
- [^] # Re: Bazel
  
  Posté par Firwen (site web personnel) le 15 juin 2018 à 17:16. Évalué à 4.
  Il y a des gens qui ont essayé Bazel ?
  - Horriblement bloaté ( e.g, requiert une JVM pour compiler un hello world en C )
  - Inflexible, hardcode compiler path et autre joyeusement
  - Ne suit pas le standard make / make install. Essaie de compiler tout dans un "workspace"
  - Je le rank assez haut au ranking des pires build systèmes available.
# gprbuild

Posté par Meku (site web personnel) le 15 juin 2018 à 19:21. Évalué à 4.

Alors dans le monde (souvent oublié) d'Ada, il y a gprbuild (« gpr » pour GNAT project, GNAT étant le compilateur développé par AdaCore et reposant sur GCC).

Avec gprbuild, on décrit son projet dans un fichier .gpr dans une syntaxe qui rappelle l'Ada. C'est donc facile à lire pour un humain. Et c'est pas mal fichu car pas chiant à écrire non plus tout compte fait. Le démarrage d'un fichier projet est assez rapide (3-4 directives pour spécifier les répertoires contenant les sources, les produits de compilation, les binaires), et ça reste généralement assez concis. Et si on a besoin de faire des choses un peu évoluées (avec des switch/case sur des variables d'environnement par exemple), la syntaxe permet de construire son projet de manière assez propre.

Pour les dépendances, il suffit d'une directive « with madependence.gpr » en début de projet, comme un include (il faut que la dépendance soit décrite dans un fichier .gpr bien sûr), et hop ça link automatiquement avec.

Ça gère quelques langages, qu'on peut mixer en même temps d'ailleurs (Ada, C, C++).

C'est le bonheur d'avoir des fichiers projet tout beau et tout propre, faciles à lire et à maintenir.
# et d'autres : tup, buck

Posté par nokomprendo (site web personnel) le 15 juin 2018 à 21:36. Évalué à 3.

http://gittup.org/tup/
https://buckbuild.com/

J'ai utilisé un peu Tup : c'était concis et rapide mais assez particulier à configurer.

Buck, je ne connais que de nom, si quelqu'un à un retour…
# Eclipse

Posté par ilip le 16 juin 2018 à 10:49. Évalué à 2.

Peut-être hors sujet mais personnellement j'utilise Éclipse CDT pour les projets C/C++, qui créé des Makefiles pour le build, avec détection des toolchains disponible sur le poste. L'interface de configuration du projet pour les librairies est assez bien faite. Le projet est enregistré en .project. Par contre je ne sais pas si c'est utilisable de manière portable.
- [^] # Re: Eclipse
  
  Posté par Selso (site web personnel) le 13 juillet 2018 à 10:37. Évalué à 0.
  
  CDT est un outil très populaire finalement, il est utilisé par beaucoup de distributeurs qui intègrent leur SDK à Eclipse.
  
  Portable : oui et non….
  Nous l'utilisons indirectement, les conf de build doivent être adaptées pour la personne qui build sous Linux.
  A l'époque les makefiles générés utilisait des chemins en absolu, ce qui rendait impossible l'usage d'un script pour la compilation en CLI, sur un autre poste.
  Maintenant je ne sais pas je n'ai pas trouvé les Makefile ("internal builder is used, generate Makefile automatically")
# Manquent à l'appel WAF et jam

Posté par Philippe F (site web personnel) le 16 juin 2018 à 22:40. Évalué à 3.

On peut citer aussi Waf. Le développement avait été lancé par un français à l'époque où KDE se tatait pour changer de système de build et hésitait entre SCONS et CMake. Le développeur initial (Thomas Nagy) a d'abord poussé SCONS puis devant son inefficacité, a développé WAF.

Il a l'air d'être toujours activement maintenant: https://waf.io/

Niveau usage, aucune idée si ça tient la route mais on peut voir quand même des beaux projets dans les utilisateurs : Samba, Ardour.

Egalement manquant, Boost.Build + jam, utilisé pour construire rien de moins que les libs boost, une des références pour quiconque fait du C++ avancé (ou suit un peu les standard du C++). Je l'avais utilisé il y a bien une dizaine d'année et j'avais tout de suite remplacé ça par un peu de qmake (tmake à l'époque), vu que je comprenais mieux comment ça marchait.
- [^] # Re: Manquent à l'appel WAF et jam
  
  Posté par Ely le 17 juin 2018 à 07:36. Évalué à 2.
  
  mpv utilise waf, c'est vrai qu'en tant qu'utilisateur ça rend le build très simple. Après je ne sais pas vraiment comment sont écrits les fichiers de build waf, faudrait que je regarde..
- [^] # Re: Manquent à l'appel WAF et jam
  
  Posté par Thierry Thomas (site web personnel, Mastodon) le 19 juin 2018 à 16:24. Évalué à 3.
  
  Autre exemple de gros projet qui utilise Waf : Code_Aster.
# Le vrai débat : build natif de la plate-forme ou build générique

Posté par Philippe F (site web personnel) le 16 juin 2018 à 23:02. Évalué à 10.

On passe à côté du vrai débat.

Un des points très forts de CMake, et il est un des seuls à arriver à ce niveau de fonctionnalité (suivi de près par qmake tout de même), c'est de générer des fichiers projets pour l'IDE de référence de la plate-forme cible.

Pour Windows, il génère des projets Visual Studio, et les compile avec Visual Studio. Pour OS X, ce sont des fichiers XCode. Pour Linux, c'est des Makefile, principalement parce que quand CMake a été conçu, c'était parmi ce qu'il y avait de mieux.

Pourquoi c'est important ? Parce que contrairement au monde Unix où la compilation est avant-tout un agencement élaboré d'outil en ligne de commande qui peuvent être chapeautés par divers "pilotes" (Make, ninja, jam, waf, …), sur les deux plate-forme propriétaires de référence, la compilation est plutôt vue comme l'une des tâches d'un IDE. Même si cet IDE ne fait que lancer des outils en lignes de commandes, il y a beaucoup de subtilités sur l'utilisation de cette ligne de commande, et elle est beaucoup moins bien documenté vu que globalement, tout le monde utilise l'IDE.

Par exemple, sous Windows, si tu veux que ton programme ait une jolie icône de lancement, il faut embarquer l’icône sous forme de ressource dans le .exe . Ça se fait en environ une minute sous Visual Studio. Pour faire la même chose avec un Makefile, tu y passeras facile une demi-journée. Il semble d'après la lecture de l'article que MacOs X, IOS et Android aient aussi ce genre de chausse-trappe.

Du coup, générer des fichiers projets, c'est important quand on fait de la grande portabilité hétérogène comme l'auteur ici. Et CMake s'en sort bien.

Même si ça ne va pas sans son lot d'inconvénient : du fait de la diversité des capacités des IDE, le comportement et le niveau d'optimisation qu'on peut en attendre est limité. C'est le plus petit dénominateur commun qui s'applique. Je me rappelle avoir essayé de générer avec CMake un fichier Visual Studio qui tirerai partie des fonctionnalités post-build de Visual, c'était mission impossible. Pas portable d'une part, et même pas bidouillable si on accèpte de sacrifier la portabilité.

Du côté du monde Unix, la compilation étant un assemblage de lignes de commande bien documentées, il est possible de jouer pas mal avec la façon dont on pilote tout ça. D'où la pléthore d'outils cités, qui peuvent se focaliser plus des aspects particuliers de la gestion d'un build (notamment la performance), et peuvent écrabouiller CMake sur cet aspect. Sauf que … ils peuvent se retrouver complètement inutilisables dans un environnement propriétaire dédié car demandant trop de temps au développeur pour maitriser la chaine de compile de la plate-forme cible.

Générer un fichier projet permet aussi d'interagir avec des développeurs de l'équipe qui utilisent ces IDE de référence. Par exemple, le debug de C++ sous Visual est extrêmement bien fait, mais passe par l'IDE. Ce serait dommage de s'en priver juste parce que ninja est hyper mieux que nmake (le make de Visual Studio) mais ne sait pas lancer un IDE en mode debug.

Bref, à mon avis, malgré ses faiblesses, CMake a encore de beaux jours devant lui.
# Le gral n'a pas été trouvé.

Posté par Selso (site web personnel) le 12 juillet 2018 à 10:29. Évalué à 1.

Très intéressant comme retour d'expérience, as-tu testé également qmake ? il est certe associé à Qt mais peut-être utilisé pour un projet indépendant il me semble.
Lui aussi dispose d'outils pour gérer du multi-plateforme puisque c'est également l'objectif du framework d'être présent sur les OS desktop/mobiles.

Je suis plutôt d'accord avec les évaluations des autotools, make et cmake.
Make reste un bon candidat pour des petits projets, c'est simple pratique. Si on a déjà notre "makefile générique" on s'en sort à bon compte. Sous windows il m'est arrivé d'utiliser "git bash" couplé à mingw pour une génération à base de Makefile.

Les autotools c'est l'usine à gaz avec en plus les syntaxes à maîtriser : M4, bash, Make, etc…
L'on m'avait dit à l'époque que c'était plus pour gérer les chaînes de compilation UNIX que les OS, ce qui explique pourquoi Windows est très mal supporté (ou pas du tout) et tout le travail du configure de vérifier les capacités de la chaîne de compilation.

cmake je m'en suis juste servi à l'occasion et j'ai trouvé ça plus "fonctionnel", plus abordable, avec la capacité à générer des fichiers projets pour nos IDEs.

Suivre le flux des commentaires

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