Bonjour Nal,
Je vais bientôt me retrouver face à un dilemme insoluble : choisir la bonne version minimum de CMake pour écrire un CMakeLists.txt. Jusqu'à présent, ma distribution préférée avait CMake 3.0.2 dans sa mouture stable. Donc, c'est celle que j'utilisais et c'est celle que je prenais comme version minimum. Déjà, ça me posait un certain nombre de problème parce que dans Ubuntu Trusty (la LTS de 2014), qui est installé dans mon univ, CMake en est à la version 2.8.12 et que je veux bien faire un effort mais bon voilà.
Dans la prochaine Debian stable prévue pour très bientôt (voir la dépêche en cours de rédaction), CMake passe directement en 3.7.2. Et là, je me dis «Modern CMake» toussa, ça va être trop bien. Sauf qu'à y regarder de plus près, tout le monde n'en est pas à CMake 3.7 et que je n'ai sans doute pas besoin de toutes les fonctionnalités de CMake 3.7.
En regardant un peu, je me dis qu'il manque target_compile_features qui peut être sympa (apparu en 3.1). Mais sur le reste, je ne vois pas bien ce que les versions suivantes pourraient avoir de vital. Alors, cher Nal, voici ma question : est-ce que tu utilises Modern CMake ? De quelle fonctionnalité indispensable vais-je avoir besoin qui va changer ma vie avec CMake ? Éclaire ma lanterne !
# version minimum possible
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 08 juin 2017 à 09:38.
Pour une question de "portabilité" je me baserai sur la version la plus basse utilisée par les différentes distros qui sont en support long terme et qui sont encore activement supportées.
Tant chez ubuntu que chez redhat/Centos c'est du 2.8.12. Après tu ne seras peut-être pas obligé d'attendre 2020 (fin de la phase production 3 de redhat6) pour passer à une version supérieure. Après tout cmake c'est fait essenctiellement pour construire des packages donc ça n'a rien à faire sur des machines de production et c'est pas comme si c'était dur d'installer une autre version de cmake et de la mettre dans son path avant un build.
Après je n'ai aucune idée du type de projets sur lesquels tu travaille ni quel est le public destiné.
[^] # Re: version minimum possible
Posté par rewind (Mastodon) . Évalué à 2.
Chez Ubuntu, la dernière LTS est xenial (16.04) et la version de CMake est 3.5.1. Après, RedHat, j'ai envie de dire : tant pis.
Toute sorte de programmes en C++, et plus particulièrement des jeux vidéos. En l'occurrence, c'est pour une bibliothèque de jeux vidéos que je pose la question, mais je pense que ce n'est pas propre à ce type de bibliothèque et qu'on peut avoir cette problématique dès lors qu'on distribue un logiciel libre en C++.
[^] # Re: version minimum possible
Posté par Psychofox (Mastodon) . Évalué à 2.
Je pensais à la plus ancienne LTS supportée en fait.
Au contraire je pense que la problématique est différente si tu tapes sur des trucs utilisés dans le monde professionnel sur des serveurs de prod (bien que la tendance actuelle tend rarement à recompiler ses binaires soi-même) ou un truc comme les bibliothèques de jeux vidéos qui va viser un public dont les versions des distribs seront mises à jours plus souvent.
# cmake-server
Posté par EdesMerkis . Évalué à 1.
La première nouveauté qui me vient à l'esprit est le mode "serveur" qui est apparu avec CMake 3.7. Il semble que cette fonctionnalité soit utilisée par visual studio 2017 et Qt Creator 4.3. Elle permet à l'IDE de dialoguer avec CMake.
Deux liens :
- CMake support in Qt Creator.
- La doc de CMake
Bien sûr ce changement n'a pas d'impact sur l'utilisation de CMake dans un projet quelconque.
[^] # Re: cmake-server
Posté par rewind (Mastodon) . Évalué à 3.
Attention, il y a une différence entre la version minimum requise et la version effectivement utilisée. La version minimum requise est une contrainte pour celui qui écrit le
CMakeLists.txtparce qu'il n'aura pas accès à toutes les fonctionnalités apparu dans les versions suivante. Après, rien n'empêche d'utiliser une version très récente de CMake avec ceCMakeLists.txtet de profiter de certaines avancées comme le mode serveur.# Désolé de répondre à coté de la plaque
Posté par calandoa . Évalué à -4.
… car c'est toujours pénible quand on cherche de l'aide d'avoir des mecs qui te disent « faut pas faire comme ça »… mais sur ce sujet, j'ai du mal à me retenir.
Je suis passé par pas mal d'outils de build, et franchement, c'est à chaque fois n'importe quoi. Tous ces outils qui sont censés te simplifier la vie te la complique deux fois plus, et pour les utilisateurs qui vont tenter de recompiler tes sources dans un environnement différent, 10 fois plus.
Utilise un simple GNU make. Oui, il y a plein de fonctionnalités qui manquent et c'est pas toujours très bien pensé, mais au final c'est extrêmement standard et facile à debugger pour tout le monde (à condition de ne pas partir dans des machines à gaz récursives) et tout les problèmes que tu peux avoir ont sans doute déjà une solution référencée par google.
[^] # Re: Désolé de répondre à coté de la plaque
Posté par Renault (site web personnel) . Évalué à 7.
Je ne suis pas d'accord.
Les outils tels que cmake ou autotools sont vachement pratiques en cas de compilation sur des systèmes différents ou pour la compilation croisée.
Quand tu fais de la compilation croisée (cas typique avec Yocto ou buildroot), utiliser ce genre d'outils simplifie énormément le travail de la personne qui souhaite intégrer la bibliothèque dans cet environnement de développement. Je présume que c'est pareil pour la génération des paquets des distributions.
Un simple make est rarement suffisant dans le cadre d'un logiciel distribué plus largement que par le binaire fourni par son concepteur. Et faire en sorte que le make soit assez propre pour tenir compte des particularités de chacun revient à faire des systèmes similaires que ceux que tu critiques. C'est très difficile à faire.
[^] # Re: Désolé de répondre à coté de la plaque
Posté par calandoa . Évalué à 5.
Tu cites autotools, et ça tombe bien car je crois bien que c'est un des pires outils que j'ai utilisé en tant que développeur principal ou utilisateur compilant des sources. Dans 95% des cas, tout va bien marcher… mais dans les 5% restants, ça va être l'enfer pour remonter à travers les makefiles et les scripts faisant des milliers de ligne pour comprendre le problème (sans parler des scripts m4 et des fichiers de conf ayant chacun une syntaxe différente).
Si je dois donner une estimation au doigt mouillé (après 10 ans de slackware) les autotools vont se planter dans 5% des cas avec au moins 30mn de debug, et les makefiles simple dans 10% des cas avec 5mn de debug.
L'outil que j'avais le plus apprécié était SCons qui avait l'immense avantage d'utiliser du python et uniquement du python (même avec du makefile simple, il faut parfois passer par du shell ou autres scripts). Mais au final, j'ai gardé un avis assez mitigé avec cet outil, notamment à cause de bugs fumeux avec cygwin.
[^] # Re: Désolé de répondre à coté de la plaque
Posté par Spyhawk . Évalué à 3.
Ils simplifient la vie du développeur, mais c'est la fragmentation des distributions et les vieilles versions qui sont responsables de beaucoup des problèmes qui n'ont pas lieu d'être. De mon point de vue qui vaut ce qu'il vaut, le développeur peut simplement mettre à disposition une version de son projet compilé statiquement qui fonctionnera partout, mais ce n'est pas son rôle de faire en sorte que les sources publiées soient compilables par quelques barbus sur Debian 6 ou RHEL 3 (encore plus vrai pour des jeux, ou la simple dernière Debian stable peut être un cauchemar).
En gros, il faut utiliser ces outils qui sont censés simplifier la vie de façon qu'ils la simplifient, mais ce n'est pas à lui d'assumer le choix de distrib des utilisateurs.
[^] # Re: Désolé de répondre à coté de la plaque
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
J'aimerais penser que c'est une blague mais j'ai l'impression que non.
Alors oui, il faut savoir comment Make marche et il faut donc avoir déjà étudié et créé des Makefiles. Mais une fois passé le stade de l'apprentissage, ne jamais faire ses makefiles à la main dans des projets réels. Utilisez les autotools, CMake, Meson peut-être (ça a la côte et certains disent que c'est l'avenir, à voir…), que sais-je… mais n'écrivez pas des makefiles à la main!
Les bons systèmes de build vous apporteront:
une portabilité automatique sur plein de plateformes.
Ex: sur GIMP, quand on est passé à GExiv2, personne arrivait à le compiler pour Windows. Les dévs de GExiv2 eux-même n'étaient pas sûr si c'était possible puisqu'ils n'avaient pensé qu'aux plateformes Linux jusque là. À l'époque, ils utilisaient un makefile fait à la main justement et c'était la misère. Comme c'était devenu une dépendance majeure pour nous, j'ai porté GExiv2 sur les autotools. Le projet est devenu cross-plateforme instantanément et comme il était écrit de manière générique, il a pu être compilé pour Windows sans se poser de question.
La cross-compilation simple: cross-compiler avec des systèmes de build bien faits est quasi aussi simple qu'une compilation native.
Ex: libmypaint utilisait Scons et c'était aussi terrible (je n'ai jamais vu aucun projet utiliser Scons bien, alors j'ai un mauvais a-priori dessus). Des gens arrivaient apparemment à compiler nativement pour Windows, mais pas à cross-compiler. Au final j'ai aussi porté libmypaint sous autotools et maintenant je le cross-compile en quelques minutes sans me poser de questions.
Un standard: autotools utilise les "cibles" standards de GNU ("install", "uninstall", "clean", etc.). Cela rend la compilation très aisé de divers projets dont la compilation fonctionne toujours pareil. C'est un peu moins bon côté CMake pour lequel il manque certaines cibles, et aussi pour lequel on voit régulièrement des "irrégularités". Mais globalement même CMake, avec le temps, les projets tendent à utiliser les mêmes cibles (un standard de fait se crée).
Les compilations "VPATH": on peut compiler aisément et par défaut depuis un autre répertoire que le répertoire source. Cela permet notamment de créer plusieurs builds à partir d'un même source sans conflits (options différentes, ou des cross-compilations justement, etc.).
Simplification: un makefile qui a toutes les fonctionnalités qu'on veut (multi-plateformes, plein de cibles, gestion de compilation, installation, désinstallation, nettoyage, tests unitaires…), ben c'est compliqué. Faire tout ça à la main serait un temps plein rien que pour débugguer constamment. Donc on délègue au système de build. Cela rend la gestion de projet bien plus simple tout en ayant un build avec plein de fonctionnalités.
Les tests unitaires (make check).
La création de paquets sources (
make dist) et leur vérification (make distcheckqui crée le paquet puis recompile et joue les tests unitaires à partir du paquet)!La gestion avancée de la configuration avant compilation.
J'en passe problablement beaucoup. C'est ce qu'il me vient à l'esprit.
Donc non, pas de makefile basique. À part peut-être pour un projet super simple avec juste quelques fichiers ou un projet temporaire. Et encore…
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Désolé de répondre à coté de la plaque
Posté par calandoa . Évalué à 1.
J'ai récemment utilisé maven pour compiler un simple programme pour android. Et j'aurais moi aussi aimé penser qu'il s'agissait d'une blague, plutôt que d'être un cauchemar sans nom. Visiblement, l'outil est conçu pour faire plein de choses que tu cites, et sans doute le café et jouer des mp3 pendant la compilation mais il a juste oublié une chose : marcher. J'ai du aller récupérer successivement plusieurs versions stables successives de sources de cet outil et les recompiler toutes une par une avant de trouver celle qui correspondait exactement aux fichiers de conf du projet final, sachant que les dépendances elles aussi devaient correspondre à des versions particulières. Résultat : une après-midi de perdue pour compiler un petit projet ridicule (car bien sûr, après chaque echec, on se dit: « il y a juste ça à corriger et ça va marcher direct »)… et heureusement que google était là.
La plupart de ces outils seraient sans doute les meilleurs choix si ils avaient tous la maturité et la stabilité de make, malheureusement, il s'en crée sans arrêt de nouveaux, et les anciens se sentent obligés de rajouter de nouvelles fonctionnalités pour être sûr de bien planter à la prochaine release d'ubuntu.
En fait je viens de relire ton message, et je vois que j'ai raté : « les bons systèmes de build ». Désolé, je n'avais pas compris que tu parlais d'un futur utopique et non de la triste réalité.
[^] # Re: Désolé de répondre à coté de la plaque
Posté par liberforce (site web personnel) . Évalué à 2.
Bah jette un coup d'oeil à Meson.
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.html
https://samthursfield.wordpress.com/2017/05/22/tracker-%F0%9F%92%99-meson/
http://mesonbuild.com/Simple-comparison.html
[^] # Re: Désolé de répondre à coté de la plaque
Posté par rewind (Mastodon) . Évalué à 3.
Le développeur a l'air d'être très imbu de lui-même, il prend souvent les gens de haut, il s'est déjà fait une petite réputation négative (non, non, il ne s'appelle pas Lennart). Il sur-vend beaucoup son projet, mais pour moi, il est loin de valoir CMake sur plein d'aspects. Et pourtant, j'estime qu'avec CMake, on est loin de ce qu'on pourrait attendre d'un programme de ce genre.
[^] # Re: Désolé de répondre à coté de la plaque
Posté par liberforce (site web personnel) . Évalué à 2.
J'aimerais bien savoir en quoi il sur-vend son projet…
Les retours de plein de projets (tracker, gstreamer, gnome) sont très positifs sur le produit comme sur l'écoute des devs, et Mesa et X envisagent aussi une migration…
[^] # Re: Désolé de répondre à coté de la plaque
Posté par rewind (Mastodon) . Évalué à 2.
Il le sur-vend parce qu'il ne résout quasiment aucun problème de plus que ceux déjà résolus par CMake. Et pourtant, il le vend comme un truc qui va révolutionner le monde. Que des projets trouvent leur compte dans Meson par rapport aux autotools, je le comprends parfaitement. Mais quand on a déjà CMake en place, Meson n'apporte rien, malgré tout ce que peut dire son concepteur.
Pourtant, il y aurait de quoi faire pour ce genre d'outils pour améliorer le quotidien.
[^] # Re: Désolé de répondre à coté de la plaque
Posté par Jehan (site web personnel, Mastodon) . Évalué à 3.
Tu survends un peu CMake dans ton cas, j'ai l'impression. Tu es en train de dire implicitement que CMake est genre évidemment mieux qu'autotools? Ou je me méprends?
Parce que pour bien connaître les 2, ils ont clairement chacun des avantages et inconvénients. J'aime beaucoup la configuration dans CMake, notamment le fait que ça ne s'arrête pas à chaque dépendance manquante, et qu'on a un résumé à la fin. Similairement cela permet des outils comme
ccmake(que j'utilise toujours perso sur des projets avec un build CMake) pour avoir une vue d'ensemble des dépendances et options.J'aime aussi la sortie d'un build créé par CMake qui est plus agréable et lisible.
Par contre, CMake a son lot de problème aussi. Il lui manque des targets par défaut. Ils ont un peu complexifié la compilation croisé avec les fichiers toolchains. Bien sûr la fonctionnalité des fichiers toolchains est utile, mais dans 99% des cas, c'est inutile. Se contenter du préfixe commun à tous les outils de la toolchain est suffisant (comme autotools). Le fait de ne pas être dans un langage de script classique complexifie les particularités que l'on veut donner à notre build (dans autotools, c'est du shell). C'est faisable mais faut faire plus de détours par des macros CMake.
Enfin voilà. Autotools est loin loiiin d'être parfait, mais perso je mets CMake au même niveau.
Meson, je sais pas. Pas encore essayé. Si je pige bien, ses développeurs mettent surtout en avant sa vitesse, bien sûr par de la compilation même mais surtout de la partie script entre la compilation (qui prend en effet beaucoup de temps avec des Makefiles). Sur cela, CMake a aussi l'avantage de pouvoir utiliser ninja en backend optionnel (comme Meson). Ceci dit, les tests de vitesse effectués par le projet Meson sont un peu ridicules. Ils se basent sur un faux build qui se fait en quelques dizaines de secondes. Les grosses différences qu'on voit alors, comment savoir si ce sont des temps fixes ou proportionnels? C'est comme le temps de configuration, autotools est le gros perdant, mais bon… c'est pas comme si on reconfigure constamment et comme si les quelques secondes prises pour configurer (qui sont fixes) sont vraiment comparables à une compilation de 2 heures!
Ce test n'a donc aucun intérêt. J'attends de voir des comparaisons sur de vrais projets qui mettent 30 minutes au moins à compiler.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Désolé de répondre à coté de la plaque
Posté par Renault (site web personnel) . Évalué à 3.
Oui et non.
Déjà dans le cadre d'une intégration continue, ton serveur de validation peut (et je dirais même, doit) recompiler depuis 0 à chaque commit. Cela inclus le temps de configuration qui devient systématique.
Et puis, dans le cadre de mon travail, nous utilisons Yocto ou buildroot pour générer l'image finale du système. Ces systèmes compilent des dizaines / centaines de projets simultanément. On avait mesuré le temps pris pour valider un nouveau commit par Jenkins. Le rapport était édifiant, 33% du temps était perdu dans l'étape de configuration ! Sur une compilation globale de 45 minutes environ, cela donne près de 15 minutes pour chaque commit. Quand tu as des dizaines de commits à valider par jour, cela monte vite en terme de temps perdu.
[^] # Re: Désolé de répondre à coté de la plaque
Posté par calandoa . Évalué à 2.
Ce qui est quand même assez rigolo avec vos histoires, c'est que vous n'arrivez pas trop à vous mettre d'accord sur ce qu'apporte vraiment CMake, le tout dans un journal ou l'auteur est bloqué par des histoires de versions suffisamment tordues pour venir demander son avis à tout le monde.
Personnellement, je n'ai jamais vu un message sur la bonne version de GNU make à utiliser (bon j'avoue, j'ai déjà entendu parler de problèmes de compatibilité GNU/non-GNU).
Pour Meson, je ne connais pas, donc peux difficilement critiquer… il faudrait que je tente de l'utiliser un jour (malgré un mauvais pressentiment).
[^] # Re: Désolé de répondre à coté de la plaque
Posté par Jehan (site web personnel, Mastodon) . Évalué à 2.
On sait exactement ce qu'apporte CMake par rapport à des Makefiles nus. J'ai même listé plusieurs de ces choses, dont certaines primordiales. La discussion a simplement dérivé sur les différences entre ces systèmes de build avancés. Pour la comparaison entre un Makefile nu et n'importe lequel de ces systèmes de build, voir les nombreux messages précédents. Franchement même en discuter me paraît ridicule à ce point là.
Aussi je sais pas si tu en es conscient, mais ces systèmes de builds produisent aussi des Makefiles (en tous cas pour les autotools, ainsi que pour CMake par défaut). Ce sont simplement des interfaces de plus haut niveau à Make qui permettent de gérer de gros projets, mais au final, on exécute make. La comparaison est donc toute relative.
En tous les cas, j'aimerais bien savoir avec quel genre de projets tu te bases comme expérience pour nous sortir que des Makefiles écrits soi-même seront plus efficaces que n'importe lequel des systèmes de build cités.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Désolé de répondre à coté de la plaque
Posté par calandoa . Évalué à 1.
Attention ! je ne dis pas que le make simple est plus efficace… je suis bien d'accord que c'est assez limité et que la syntaxe est assez foireuse. je dis simplement que c'est le moins galère à gérer pour soi même, et surtout pour des utilisateurs externes au projet.
[^] # Re: Désolé de répondre à coté de la plaque
Posté par rewind (Mastodon) . Évalué à 3.
Là, nous avons une divergence. Je mets CMake très au dessus d'Autotools. Tu parles de la syntaxe de CMake mais tu oublies que les Autotools ne sont pas que du shell, il y a aussi toute une palanquée de scripts en M4.
Après, je conviens très facilement que CMake est très loin d'être parfait. Mais c'est un peu le standard de fait dans le monde C++ et ça marche suffisamment bien pour mon cas d'utilisation pour que je le garde.
C'est aussi ce genre de trucs qui me font dire que Meson est sur-vendu.
[^] # Re: Désolé de répondre à coté de la plaque
Posté par liberforce (site web personnel) . Évalué à 2.
Genre GStreamer ?
La comparaison est faite par rapport à l'ancien build en autotools.
Source:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.html
[^] # Re: Désolé de répondre à coté de la plaque
Posté par rewind (Mastodon) . Évalué à 5.
Je vais aller dans le sens des réponses précédentes, mais un
Makefilenu, c'est bien quand on vit dans une grotte. Là, avec le mêmeCMakeLists.txt, je génère unMakefilesous Linux et un projet Visual Studio sous Windows et je n'ai aucun problème, tout compile, tout fonctionne. Si je devais faire pareil avec unMakefile, je devrais gérer deux compilateurs qui n'ont absolument rien à voir l'un avec l'autre, sur deux systèmes qui n'ont rien à voir l'un avec l'autre, et avec des gestions des dépendances (ou leur absence) qui n'ont rien à voir l'un avec l'autre. Bref, un cauchemar en perspective.# CMake 2.8.12.2
Posté par Maxime Arthaud . Évalué à 1.
On utilise cmake 2.8.12.2 au boulot, puisque c'est la version à peu prêt disponible partout (Red Hat, Debian 8, etc.), et aussi parce que c'est le minimum requis pour compiler nos dépendances (LLVM).
Un peu de
cmake_policy(), et ça roule.Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.