Mais ils intègrent tout ce qu'il faut pour faire ce que j'ai décris plus haut en une simple ligne de configuration.
Tu me montre « la simple ligne de configuration » qui permet ça dans make, gprbuild, cmake ?
Tous des langages à JVM en gros ?
Oui.
Mais si tu te sens un ame de révolutionnaire, n'hesite pas à me prouver que j'ai tord et créer ton propre plugin maven pour re-faire autotools, je suis curieux de voir....
Si tu relis ce que j'ai écris plus haut tu verra que j'ai dis que ce n'est pas forcément une bonne idée, juste que donner des arguments du genre "non mais avec C++ c'est différents" ça n'est pas pertinent parce que si tu réfléchis ton système de build par le petit bout de la lorgnette (en listant d'abord des détails) tu n'arrive pas loin et au contraire tu fini par un mauvais design.
L'objectif c'est de lancer des tâches, d'avoir un cycle de vie intéressant (1 gestion de dépendance, 2 build, 3 lancement des tests, 4 déploiement là où tu veux - par exemple -), ensuite que lors du lancement des tâches (à chaque étape) tu puisse passer le maximum d'information à l'outil en question, d'avoir la possibilité de mettre des hooks dans tous les sens, remplacer une tâche par une autre (je veux remplacer gcc par pdflatex),... ce sont des question qui :
n'ont rien avoir avec ton langage (et c'est mieux tu pourra réutiliser ton outil quand tu te mettra à rust) ;
n'ont pas à être implémentés en C++ (et c'est cool tu va pouvoir jouer à écrire ça en go).
Pour ce qui est de maven, ses 2 principaux défauts AMHA c'est :
la gestion des dépendances (je ne sais pas comment personnaliser cette partie là)
le fait que la construction (la compilation en elle même) est considérée comme une étape atomique (en une étape on compile tous les .java en .class). Donc la gestion de comment je choisi si je compile tel ou tel fichier doit être dupliquée
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Des promesses...
Posté par barmic . En réponse au journal Biicode: gestionnaire de dépendances c++. Évalué à 3.
Tu me montre « la simple ligne de configuration » qui permet ça dans make, gprbuild, cmake ?
Oui.
Si tu relis ce que j'ai écris plus haut tu verra que j'ai dis que ce n'est pas forcément une bonne idée, juste que donner des arguments du genre "non mais avec C++ c'est différents" ça n'est pas pertinent parce que si tu réfléchis ton système de build par le petit bout de la lorgnette (en listant d'abord des détails) tu n'arrive pas loin et au contraire tu fini par un mauvais design.
L'objectif c'est de lancer des tâches, d'avoir un cycle de vie intéressant (1 gestion de dépendance, 2 build, 3 lancement des tests, 4 déploiement là où tu veux - par exemple -), ensuite que lors du lancement des tâches (à chaque étape) tu puisse passer le maximum d'information à l'outil en question, d'avoir la possibilité de mettre des hooks dans tous les sens, remplacer une tâche par une autre (je veux remplacer gcc par pdflatex),... ce sont des question qui :
Pour ce qui est de maven, ses 2 principaux défauts AMHA c'est :
.javaen.class). Donc la gestion de comment je choisi si je compile tel ou tel fichier doit être dupliquéeTous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)