Discussion :

[Songbird]

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.

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.

[foetus]

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

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Songbird]

Salut,

Merci pour ta réponse aussi rapide. :o

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.

[jblecanard]

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.

[Astraya]

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/

[nathieb]

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

[Astraya]

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

[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.

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 as-tu jamais essayé les autotools (autoconf, automake, libtool et tout le reste) sous linux

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[jblecanard]

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

Ha Koala01 je savais que tu ne pourrais pas t'empêcher des les mettre sur la table . 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.

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 .

[kajtp]

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

[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.

[Songbird]

Re-bonjour,

Merci pour toutes vos réponses.

Pour te répondre koala:

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.

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.

[jblecanard]

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.

[Songbird]

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)

[koala01]

Ha Koala01 je savais que tu ne pourrais pas t'empêcher des les mettre sur la table . 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

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

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

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 "; quitte à ce que la discussion dévie par la suite sur les forces et les faiblesses comparées des différents outils

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 Le mettre, comme un trophée sur ton étagère, ou pouvoir dire "oui, je connais cet outil"

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 )

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".

[nathieb]

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

[renoo]

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).

[Songbird]

Bonjour tout le monde,

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.

[LittleWhite]

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.

[Songbird]

Salut,

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.