Alternative aux makefiles, cmake (sans EDI)

Bonjour,

Cette question a déjà dû être posée, mais je souhaiterais simplement savoir si il existe une alternative à cmake sans avoir recours à un ide ?

Pas que cmake soit (inutilement) chiant, pour rester poli, mais un peu quand même. :aie:

J'ai fait le tour des sites comparatifs, mais ils mettent cmake dans le même panier que ant et maven, alors que ce dernier se répètent quand même beaucoup moins que les deux autres.

Auriez-vous des outils de build, que vous utilisez au quotidien, et que vous recommanderiez ? (n'hésitez pas à me renvoyer autre part si il y a déjà une réponse exhaustive)

Je vous remercie d'avance pour votre réponse,

Cordialement,

Songbird.

Et un simple script bash :mrgreen:, à base de cd, mv, et gXX.

Exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

#!/bin/bash   cd ../Project_DFM_parser/Sources/Classes/ gcc -Wall -c Stack_ints.c -o Stack_ints.o gcc -Wall -c One_Element.c -o One_Element.o mv Stack_ints.o ../../../debug/.objs_gcc/Stack_ints.o mv One_Element.o ../../../debug/.objs_gcc/One_Element.o cd ../Parser/ gcc -Wall -c State_Machine.c -o State_Machine.o gcc -Wall -c Parser.c -o Parser.o mv State_Machine.o ../../../debug/.objs_gcc/State_Machine.o mv Parser.o ../../../debug/.objs_gcc/Parser.o cd ../../../debug/ gcc -Wall -o main ../Project_DFM_parser/mains/main.c .objs_gcc/Stack_ints.o .objs_gcc/One_Element.o .objs_gcc/State_Machine.o .objs_gcc/Parser.o

---

Les problèmes:

• Les chemins: en relatif ou en absolu. Cela peut poser problème si tu déplaces ton script.
• Tu vas tout recompiler. À moins de faire plus compliqué et de faire des tests d'existence.

Salut,

Merci pour ta réponse aussi rapide. :o

Citation:

---

Et un simple script bash , à base de cd, mv, et gXX.

---

Oui, j'y avais pensé, mais cela sous-entend qu'il faut réinventer la roue carrée à chaque nouveau départ. C'est marrant deux minutes. :mouarf:

Hello

Cmake est très très imparfait, mais il reste l'outil de-facto pour le C/C++. Il y a scons que personnellement je n'apprécie pas. Et il y aussi Bazel qui est encore un peu trop neuf pour savoir ce que ça va donner, mais c'est moderne pour sûr.

Pour ma part je garde un oeil attentif a Gradle avec son module C++ et la partie génération de solution visual studio en cours de dev.
https://gradle.org/getting-started-native/

Bonjour,

J'ai essayé make, ant et maven, franchement des trois, je retiens le dernier, mais c'est pas simple

Il existe, et j'ai essayé cela sur des plate-formes de dev en mobile de nouveaux outils de builds,
et franchement ils sont faciles à mettre en oeuvre et très puissants, ils sont issus du monde Node.js
et j'adore. Je parle de grunt et surtout de Gulp.

Je connais moins Gradle, mais il semble à la mode.

Olivier

Citation:

---

Je connais moins Gradle, mais il semble à la mode.

---

Gradle à été pensé pour prendre les avantages de Ant et Maven :)
A la base pour les projets Java, utiliser pour les projets Android, il est capable de gerer les projets C++ ( Merci au NDK d'android?) et d'autre language.
Dispose d'une bonne communauté :)
https://fr.wikipedia.org/wiki/Gradle

Salut,

De manière générale, il n'y aura vraiment que pour tes développements perso que tu auras vraiment le choix... Car, pour un développement pro / en équipe, tu sera bien obligé de respecter le choix qui a été fait sans doute bien avant que tu n'intègre le projet.

L'idéal est donc forcément d'arriver à en manipuler un maximum, histoire d'au moins "déjà savoir de quoi il retourne" quand tu intègre une équipe de dev qui utilise ce genre d'outils.

Mais bien sur, c'est comme tout le reste (qu'il s'agisse d'un IDE, d'un langage, d'un compilateur, d'un outil de configuration de compilation ou d'un outil d'intégration continue) : tu as le choix. Et ce choix te permet de les tester, de les aimer ou de les haïr avant de décider celui qui a ta propre préférence.

Tu te plains de cmake :question: as-tu jamais essayé les autotools (autoconf, automake, libtool et tout le reste) sous linux :question: :P

En plus, il est tout à fait possible d'éviter pas mal de répétitions en s'y prenant correctement, surtout si on arrive à bien organiser ses fichiers, et à les nommer de manière cohérente...

Perso, j'ai même trouvé le moyen de faire en sorte que les fichiers utilisés par CMake (ou par les autotools) puissent ne pas venir polluer mes dossiers contenant mes sources et être placé dans un(e hiérarchie de) dossier(s) qui leur sont propres, si bien que mes projets prennent souvent une forme proche de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

- NomProjet - CMake - doxygen - examples - lib - lib 1 - include - src - lib 2 - include - src - tests - third party

---

Citation:

---

Envoyé par koala01

Tu te plains de cmake :question: as-tu jamais essayé les autotools (autoconf, automake, libtool et tout le reste) sous linux :question: :P

---

Ha Koala01 je savais que tu ne pourrais pas t'empêcher des les mettre sur la table :mrgreen:. Sans rentrer dans le débat technique, c'est quand même dommage de monter en compétence dessus quand on sait que quasiment plus aucun nouveau projet ne se lance avec. C'est une connaissance peu réutilisable dans les années à venir. Le rapport (coût apprentissage) / utilité est moyen.

Citation:

---

Envoyé par koala01

Salut,De manière générale, il n'y aura vraiment que pour tes développements perso que tu auras vraiment le choix... Car, pour un développement pro / en équipe, tu sera bien obligé de respecter le choix qui a été fait sans doute bien avant que tu n'intègre le projet.

---

Mais s'il est la personne qui doit faire ce choix pour un projet from scratch ? Ou une migration pour moderniser la toolchain ? Avec ton expérience Koala01, je suis à peu près certain qu'on t'a déjà confié un tel choix. Ce sera probablement le cas d'autres développeurs. Donc c'est bien de se construire une compétence utilisable sur un gros projet qui monte à l'échelle, et pas seulement pour un projet perso, je trouve :).

Il me semble que qmake (il n'est pas exclusif à QT) est aussi un candidat, par contre de là à dire qu'il est moins enquiquinant et/ou plus pratique que cmake... question d'habitude je pense

Au boulot on utilise bjam, c'est celui utilisé et maintenu par boost (on écrit du jam et/ou du python). Pour des choses simples, je le trouve plus facile que cmake, mais la doc est difficile, voir incomplète.

Re-bonjour,

Merci pour toutes vos réponses.

Pour te répondre koala:

Citation:

---

L'idéal est donc forcément d'arriver à en manipuler un maximum, histoire d'au moins "déjà savoir de quoi il retourne" quand tu intègre une équipe de dev qui utilise ce genre d'outils.

---

Sauf que, pour le moment, je n'ai pas du tout l'intention de travailler en prod avec C++, donc j'aimerais me faire la main avec un outil qui me plaît plutôt que de me prendre des douches froides à chaque fois que je change de projets.

Citation:

---

Tu te plains de cmake as-tu jamais essayé les autotools (autoconf, automake, libtool et tout le reste) sous linux

---

Oui, je m'en plaint, quand on voit la qualité des gestionnaires de paquets/projets contemporains(Cargo, pub, NodeJS), j'aurais bien du mal à retourner bosser avec Ant. D'où mon voeu de me renseigner. :)

En bref, je ne souhaite pas travailler avec cet outil, je souhaite changer d'outil.

Ayant maintenant des éléments de réponses, je vais aller me renseigner. ;)

Yo

Il ne faut pas mélanger la toolchain de build et le package manager. Si ce sont deux outils qui travaillent ensemble et/ou sont implémentés ensemble, ce n'est pas nécessairement le cas.

C++ est connu pour sa faiblesse en gestion des dépendances/modules. C'est un vieux sujet qui est difficile à traiter. Ceci dit, quelques courageux se sont lancés dans l'aventure, le plus abouti à ce jour il me semble, c'est Conan.

Citation:

---

Il ne faut pas mélanger la toolchain de build et le package manager. Si ce sont deux outils qui travaillent ensemble et/ou sont implémentés ensemble, ce n'est pas nécessairement le cas.

---

Je fais bien la distinction entre les deux, mais c'est de plus en plus courant de voir les deux associés dans un seul et même outil. (d'où ma précision)

Citation:

---

Envoyé par jblecanard

Ha Koala01 je savais que tu ne pourrais pas t'empêcher des les mettre sur la table :mrgreen:. Sans rentrer dans le débat technique, c'est quand même dommage de monter en compétence dessus quand on sait que quasiment plus aucun nouveau projet ne se lance avec. C'est une connaissance peu réutilisable dans les années à venir. Le rapport (coût apprentissage) / utilité est moyen.

---

Je ne les ai pas mis sur la table en tant qu'alternative à CMake, mais plutôt que pour faire remarquer qu'il y avait moyen de tomber encore plus mal ;)

Citation:

---

Mais s'il est la personne qui doit faire ce choix pour un projet from scratch ? Ou une migration pour moderniser la toolchain ? Avec ton expérience Koala01, je suis à peu près certain qu'on t'a déjà confié un tel choix. Ce sera probablement le cas d'autres développeurs. Donc c'est bien de se construire une compétence utilisable sur un gros projet qui monte à l'échelle, et pas seulement pour un projet perso, je trouve :).

---

C'est pour cela que j'ai bien indiqué que l'idéal reste d'en connaitre un maximum :D

Mais il ne faut pas se leurrer non plus... Bien souvent, le choix est fait en fonction des préférences propres de "celui qui a les rennes du pouvoir" et qui -- à tord ou à raison estimera que "tel outil sera meilleur que tel autre"...

Ceci dit, si on peut se faire sa propre idée sur le sujet, et -- si possible -- avoir un avis objectif sur les qualités et les faiblesse des différents outils, ca permet d'alimenter la discussion ;)

Citation:

---

Envoyé par Songbird_

Sauf que, pour le moment, je n'ai pas du tout l'intention de travailler en prod avec C++, donc j'aimerais me faire la main avec un outil qui me plaît plutôt que de me prendre des douches froides à chaque fois que je change de projets.

---

Ben, la première chose à faire alors aurait sans doute de garder l'esprit ouvert, et de veiller à ne pas émettre d'avis personnel sur le sujet...

Tu aurais sans doute eu intérêt à présenter les choses sous un angle proche de "je connais tel et tel outil, mais y en a-t-il d'autre :question:"; quitte à ce que la discussion dévie par la suite sur les forces et les faiblesses comparées des différents outils ;)

Citation:

---

Envoyé par Songbird_

En bref, je ne souhaite pas travailler avec cet outil, je souhaite changer d'outil.

---

Et, selon toi, tu vas en changer pour en faire quoi :question: Le mettre, comme un trophée sur ton étagère, ou pouvoir dire "oui, je connais cet outil" :question:

Non, même si c'est pour un projet perso, on peut considérer que ce sera toujours pour travailler avec (que ce soit par décision personnelle ou par décision d'un tiers)

Mais, ceci dit, le véritable problème vient effectivement que C++ a -- en attente des modules, qui finiront bien par arriver (du moins je l'espère) -- beaucoup de mal avec les dépendances, et donc que de nombreux outils dédiés à des langages qui ne subissent pas ce problème s'avéreront au final peu utilisables avec C++.

Et puis, il y a aussi des aspects purement "idéologiques" à prendre en compte...

Par exemple, cela me fait toujours énormément de mal d'avoir à installer java uniquement pour pouvoir disposer d'un EDI comme Eclipse, alors que je m'apprête à développer du C++; et ce même si je reconnais la qualité de cet EDI. (mais bon, si, pour une raison ou une autre, j'ai besoin de java et / ou d'éclipse pour autre chose, cela ne me dérange pas forcément d'ajouter le paquet CDT au besoin ... Je suis peut être idéaliste, mais pas buté à ce point :D )

Or, Ant et marvel, pour ne citer qu'eux, entrent justement dans la catégorie d'outils impliquant des dépendances "pas forcément acceptées".

Bonjour,

L'outil de build idéal doit se faire oublier car il n'est pas le coeur de métier,
et beaucoup méritent une lanterne rouge, car dès qu'on désire un modification
c'est un investissement.

Maven est l'un d'entre eux, mais le coup d'entrée est important, et pour C++, moyen.
Par expérience, il demande tous un coup d'entrée, et souvent ils sont liés à un langage (spécificités)
ce qui est regrettable.

Un bon bash, alors !

Olivier

Citation:

---

Envoyé par jo_link_noir

Au boulot on utilise bjam, c'est celui utilisé et maintenu par boost (on écrit du jam et/ou du python). Pour des choses simples, je le trouve plus facile que cmake, mais la doc est difficile, voir incomplète.

---

Pareil j'utilise aussi bjam et bbv2 (boost build v2). La syntaxe de jam est un peu spéciale, et la doc incomplète par contre il est facile d'avoir de l'aide sur la mailing liste. Il me permet de compiler facilement sous windows et linux avec différents compilos/env (cl, gcc, clang).

Sinon il y a aussi waf/scons qui peuvent etre interessants, car le language est python (donc un "vrai" language avec une syntaxe correcte + de la doc).

Bonjour tout le monde,

Citation:

---

Ben, la première chose à faire alors aurait sans doute de garder l'esprit ouvert, et de veiller à ne pas émettre d'avis personnel sur le sujet...

Tu aurais sans doute eu intérêt à présenter les choses sous un angle proche de "je connais tel et tel outil, mais y en a-t-il d'autre "; quitte à ce que la discussion dévie par la suite sur les forces et les faiblesses comparées des différents outils

---

Bon, j'apprécie les retours, là-dessus aucun problème, en revanche les discours moralisateurs un peu moins. Je n'ouvre pas un sujet pour que l'on me fasse une leçon mais bien recevoir de l'aide, comme je peux le faire à mon tour.
Si ça te fend tant le coeur de voir l'un de tes outils chéris se faire bousculer, tu es libre de passer ton chemin... Après tout, je n'oblige personne à répondre.

Cela dit, je vous remercie pour vos réponses, j'effectuerai le reste des recherches de mon côté.

Bonne journée à tous.

Bonjour,

Je trouvais CMake utilise (sans IDE) et pouvant supporter plusieurs langage technologie. Mais bon, j'ai mis du temps à m'y habituer et je trouve que les dernières versions donnent de bons résultats.
Après, QMake, je dirais que non. De base, ça a déjà assez de souci pour supporter Qt et les projets C++ (pour la prod). Autotools, c'est déjà classé.
Il existe aussi bam.

Salut,

Citation:

---

Je trouvais CMake utilise (sans IDE) et pouvant supporter plusieurs langage technologie. Mais bon, j'ai mis du temps à m'y habituer et je trouve que les dernières versions donnent de bons résultats.

---

L'outil en lui-même est toujours bon, car il est très flexible pour répondre aux besoins de projets différents, je le trouve simplement un peu trop répétitif. C'est exactement le même problème pour Ant. Beaucoup trop verbeux pour des projets qui n'ont pas d'architectures exotiques.

Bon cela reste un avis très personnel, mais j'ai de quoi faire avec tous ces liens depuis le début de la discussion. :)

En définitive, gradle et bam me semblent être des alternatives moins verbeuses. (même si le second permet de scripter la toolchain)

Merci encore.

Ici nous utilisons Premake et Fastbuild.

J'y vais aussi de ma contribution car personne n'a encore cité waf. Je suis loin d'être afficionado de Python, mais ce build system fonctionne vraiment bien pour un investissement en temps d'apprentissage très raisonnable.

Je ne l'ai pas beaucoup utilisé mais meson a l'air sympa (simple, portable...).

Sinon, il y a tup, qui est vraiment rapide et efficace, combiné à pkg-config.

Citation:

---

Envoyé par Songbird_

Bonjour tout le monde,


Bon, j'apprécie les retours, là-dessus aucun problème, en revanche les discours moralisateurs un peu moins. Je n'ouvre pas un sujet pour que l'on me fasse une leçon mais bien recevoir de l'aide, comme je peux le faire à mon tour.

---

Je ne cherchais absolument pas à être "moralisateur"...

Par contre, il faut être bien conscient que la manière dont on pose une question influera systématiquement sur la manière dont les réponses sont apportées.

Ainsi, apporter un jugement (que je ne remet nullement en question, même si je ne partage pas ton avis) impliquera justement que les réponses s'orienteront d'avantage sur un jugement de ton jugement (essayer de te convaincre que tu as raison ou tord) que sur le fond du problème en lui-même à savoir : quels outils existent.

Citation:

---

Si ça te fend tant le coeur de voir l'un de tes outils chéris se faire bousculer, tu es libre de passer ton chemin... Après tout, je n'oblige personne à répondre.

---

Cela ne me fend pas le coeur de voir mes outils se faire bousculer, par contre, le fait que les gens n'arrivent pas à poser une question sans dénigrer (à tord ou à raison) un outil, une manière de faire ou un idée préconçue, ca, ca me chagrine énormément.

Et c'est la raison principale pour laquelle je t'ai fait (gentiment, car il ne m'a pas semblé être agressif en le faisant) une remarque sur la manière dont ta question est posée oriente forcément la réponse.

Salut,

Je viens apporter ma petite réponse: il y a premake aussi (c'est en langage lua qui semble plus simple à prendre en main).

Par contre pour CMake, il est vrai que c'est répétitif si tu ne fais pas de macro/fonction. Perso, j'ai fait une petite série de scripts CMake qui fonctionnent bien avec CMake 2.8 (sans doute avec les dernières versions également).

[EDIT]: Je n'avais pas vu la deuxième page du sujet qui parlé déjà de premake

Citation:

---

Cela ne me fend pas le coeur de voir mes outils se faire bousculer, par contre, le fait que les gens n'arrivent pas à poser une question sans dénigrer (à tord ou à raison) un outil, une manière de faire ou un idée préconçue, ca, ca me chagrine énormément.

---

Il y a des gens pour dénigrer les outils, d'autres pour écrire des pavés pour se plaindre de ces gens, la boucle est bouclée.

Non, sérieusement, ça sert à rien de jouer les butors là où le troll n'est pas.

Merci de me faire des remarques en MP, c'est inutile de polluer un thread pour ça.

Vous pouvez m’indiquer ce que vous trouvez répétitif dans cmake ? J'en ai fait un peu, et ça m'avais semblé assez direct (bien que parfois étrange) comme syntaxe.

Je ne sais pas si c'est à ça qu'il faisait référence mais apparement cmake recommande de spécificier explicitement les fichiers à compiler au lieu d'utiliser GLOB pour les collecter automatiquement. Ça devient alors effectivement assez répétitif.

http://stackoverflow.com/questions/1...files-in-cmake

Répétitif, peut être, mais ce n'est pas une chose que nous faisons tous les jours non plus. Je crois que le problème est le même sur les autotools et les développeurs s'en sont défendus et ont laissé ainsi.

Bonjour,

Citation:

---

Vous pouvez m’indiquer ce que vous trouvez répétitif dans cmake ? J'en ai fait un peu, et ça m'avais semblé assez direct (bien que parfois étrange) comme syntaxe.

---

Je "reproche" à cmake exactement la même chose qu'à Ant: Pour des très gros projets qui ont besoin d'une certaine précision dans le scripting de la toolchain, c'est adapté, par contre réécrire à chaque fois un manifest pour de petits modules qu'on souhaite importer ailleurs, c'est vite décourageant. (parce qu'il faudra pratiquement la même structure minimale pour chaque manifest)

Ce que je trouve répétitif: la déclaration des dépendances, ça m'a vite calmé quand j'ai vu l'exemple de cmake.org pour simplement linker une lib... (non pas que l'exemple soit à lui seul décourageant, mais devoir refaire toute la procédure à chaque déclaration, ça ne m'intéresse pas)

Et c'est le même problème pour Ant.

Cela n'a rien d'un troll, juste un constat personnel. (d'ailleurs ce topic n'introduisait pas au débat, sauf pour ceux qui en cherchent là où il n'y en a pas, évidemment)

Bonne journée.

Citation:

---

Envoyé par Songbird_

Ce que je trouve répétitif: la déclaration des dépendances, ça m'a vite calmé quand j'ai vu l'exemple de cmake.org pour simplement linker une lib... (non pas que l'exemple soit à lui seul décourageant, mais devoir refaire toute la procédure à chaque déclaration, ça ne m'intéresse pas)

---

Sur ce point, je ne suis pas vraiment d'accord.
Par exemple, pour linker boost thread, il suffit de charger le module

Code:

---

find_package( Boost COMPONENTS thread system REQUIRED )

---

et ensuite de l'ajouter dans les exécutables qui en ont besoin

Code:

---

1 2	add_executable( a.out main.cpp ) target_link_libraries( a.out ${Boost_THREAD_LIBRARY} ${Boost_SYSTEM_LIBRARY} )

---

Je vois difficilement comment faire plus simple; où alors j'ai mal compris le problème.

Citation:

---

Envoyé par Songbird_

Bonjour,

Ce que je trouve répétitif: la déclaration des dépendances,

---

Effectivement, l'édition de liens, quel que soit l'outil utilisé pour compiler du C++, a toujours été relativement répétitif. Mais cela n'a rien à voir avec l'outil permettant de configurer la compilation : c'est à cause du principe même d'une programmation modulaire, par laquelle nous veillons à ne mettre que "aussi peu de choses" que possible dans chaque unité de compilation.

Après, il faut bien forcément regrouper tous ces "petits morceaux" d'une manière ou d'une autre, afin d'obtenir l'exécutable final ;)

Et ca, il n'y a rien à faire, C et C++ ont choisi une manière de faire (qui n'est très certainement pas la plus intéressante qui soit), et nous devons donc "faire avec". Et il n'y a au final aucun outil qui pourra nous macher le travail ;)

Citation:

---

ça m'a vite calmé quand j'ai vu l'exemple de cmake.org pour simplement linker une lib... (non pas que l'exemple soit à lui seul décourageant, mais devoir refaire toute la procédure à chaque déclaration, ça ne m'intéresse pas)

---

Ca, malheureusement, tu n'as pas le choix : tôt ou tard, la chaine de compilation a besoin d'un certain nombre d'informations telles que:

• où aller chercher les fichiers d'en-tête
• où aller chercher les bibliothèques afin de founir la partie binaire correspondant aux fonctionnalités issues des bibliothèques tierces

Et comme tout nous incite à travailler par module, par bibliothèques (si possible en faisant en sorte que chaque module soit aussi indépendant que faire se peu des autres), il faut bien trouver le moyen de fournir ces informations d'une manière ou d'une autre.

Et oui, cela signifie que, si tu as dix modules différents dans ton projet, hé bien, tu devras veiller à fournir toutes les informations nécessaires à chacun de ces modules, et donc, que tu retrouveras certaines de ces informations à plusieurs endroits.

Mais, si tu organises correctement ces dix modules, il est tout à fait possible de faire en sorte d'ajouter automatiquement la dépendance sur "le dernier module précédant" pour qu'elle soit prise en compte pour "les modules qui seront compilés après", et ce, sans avoir besoin de copier quoi que ce soit (ou peu s'en faut).

Mais il ne faut pas oublier que cmake ou les autotools fonctionnent parfaitement sur des arborescences de dossiers particulièrement complexes, et que ce qu'il connaissent dans un dossier parent est connu dans le dossier enfant, et en définissant les bonnes variables aux bons endroits, il est parfaitement possible d'obtenir quelque chose où les répétitions se trouvent limitées aux stricte minimum

Si bien que je me pose sincèrement la question de savoir la répétition à laquelle tu dis avoir été confronté est du à l'outil ou à l'organisation même de ton projet.

Dis toi bien que je ne juge absolument pas là. Je ne sais rien du projet pour lequel tu as commencé à haïr cmake, je ne suis donc absolument pas en mesure de me faire la moindre opinion à son sujet. Mais il faut se rendre compte que, si le projet est physiquement mal organisé au départ (et je me garderai bien de dire que c'est le cas du tien), aucun outil ne pourras éviter de te prendre les pieds dans le tapis : les différents outils dont on dispose ne sont jamais que des aide, ce ne sont pas des solutions miracles

Sous linux, les autotools c'est sympa je trouve.