mais des arguments contre intéressants j'en ai pas vu dans le commentaire parent.
Tu arrives un peu tard Michel ^ Mais peu importe, je vais essayer d'être plus clair.
Mon commentaire précédent pourrait se résumer à "Concernant les tools de compilations, evil is in the details" et par conséquent un outil designé pour un language est bien souvent inadapté pour un autre.
Les builds tools sont bien plus compliqués qu'il n'y parait dés qu'on creuse un peu.
Ça n'a rien à voir avec Maven ou pas maven.
Je conseillerais vivement la personne qui utilise autotools pour gérer un projet complètement en python d'aller voir un psy: c'est du sadomasochisme, ça n'a jamais été fait pour ça.
Il en va de même pour Java et Maven: Maven a principalement été conçu avec Java en tête : il est déclaratif, minimaliste, adapté à une chaine de compilation relativement simple pour un langage à bytecode multi-plateforme.
Maintenant, compare ça à C/C++ avec cmake ou autotools qui sont les mastodontes du secteurs pour de bonne raisons.
Ils gèrent un véritable dictionnaire de fonctionnalités nécessaires à la compil C/C++ :
ils sont capable de générer des micro programmes, de les compiler et de vérifier le résultat pour tester le support du compiler pour
une fonction
un header
une signature
ils parsent / transforment dynamiquement suivant la configuration/plateforme les headers de configurations ( les fameux config.h ) automatiquement pour garantir une certaine portabilités entre plateforme avant de les compiler
ils gèrent de manière transparente le bordel liés à la multi-tudes d'options et de paramètre différents propre à chaque linker et à chaque compiler.
ils changent les options passé au compilateurs suivant l'OS, la plateforme, l'architecture
ils détectent et enregistre la dernière date de modification ( ou checksum ) de chaque fichier du projet ( et uniquement du projet ) pour ne recompiler QUE les fichiers qui ont changer et minimiser les temps de compilations relativement long du C/C++.
ils créent des arbres de dépendance pour pouvoir paralléliser la compilation de chaque fichier "objet" / shared library / executable sans causer des problèmes de linkages.
ils doivent pouvoir supporter une gestion à la fois "automatique" et "fine grain" pour pouvoir supporter tous les hacks propres à la compilation C/C++
inclusion code assembleur
double compilation, cross compilations
symbol versioning
rpath
symbol stripping
etc, etc, etc... ....
Et j'en oublie encore beaucoup. Les build systems C/C++ sont des usines à gaz et c'est pas juste pour le plaisir de les rendre monstrueux.
Maven ne supporte pas ça, n'est pas adapté pour ça, ne le sera sûrement jamais.... Et à mon humble avis, ne doit pas essayer de l'être.... sous peine de devenir un bordel encore plus complexe que les autotools eux même.
[^] # Re: Des promesses...
Posté par Firwen (site web personnel) . En réponse au journal Biicode: gestionnaire de dépendances c++. Évalué à 3. Dernière modification le 07 avril 2015 à 23:12.
Tu arrives un peu tard Michel ^ Mais peu importe, je vais essayer d'être plus clair.
Mon commentaire précédent pourrait se résumer à "Concernant les tools de compilations, evil is in the details" et par conséquent un outil designé pour un language est bien souvent inadapté pour un autre.
Les builds tools sont bien plus compliqués qu'il n'y parait dés qu'on creuse un peu.
Ça n'a rien à voir avec Maven ou pas maven.
Je conseillerais vivement la personne qui utilise autotools pour gérer un projet complètement en python d'aller voir un psy: c'est du sadomasochisme, ça n'a jamais été fait pour ça.
Il en va de même pour Java et Maven: Maven a principalement été conçu avec Java en tête : il est déclaratif, minimaliste, adapté à une chaine de compilation relativement simple pour un langage à bytecode multi-plateforme.
Maintenant, compare ça à C/C++ avec cmake ou autotools qui sont les mastodontes du secteurs pour de bonne raisons.
Ils gèrent un véritable dictionnaire de fonctionnalités nécessaires à la compil C/C++ :
ils parsent / transforment dynamiquement suivant la configuration/plateforme les headers de configurations ( les fameux config.h ) automatiquement pour garantir une certaine portabilités entre plateforme avant de les compiler
ils gèrent de manière transparente le bordel liés à la multi-tudes d'options et de paramètre différents propre à chaque linker et à chaque compiler.
ils changent les options passé au compilateurs suivant l'OS, la plateforme, l'architecture
ils détectent et enregistre la dernière date de modification ( ou checksum ) de chaque fichier du projet ( et uniquement du projet ) pour ne recompiler QUE les fichiers qui ont changer et minimiser les temps de compilations relativement long du C/C++.
ils créent des arbres de dépendance pour pouvoir paralléliser la compilation de chaque fichier "objet" / shared library / executable sans causer des problèmes de linkages.
ils doivent pouvoir supporter une gestion à la fois "automatique" et "fine grain" pour pouvoir supporter tous les hacks propres à la compilation C/C++
Et j'en oublie encore beaucoup. Les build systems C/C++ sont des usines à gaz et c'est pas juste pour le plaisir de les rendre monstrueux.
Maven ne supporte pas ça, n'est pas adapté pour ça, ne le sera sûrement jamais.... Et à mon humble avis, ne doit pas essayer de l'être.... sous peine de devenir un bordel encore plus complexe que les autotools eux même.