Cette décision devrait seulement sur ces critères et pas zut si je veux utiliser cette lib, je vais devoir comprendre son système de build puis soit tuner l'ajouter à ma chaîne de compilation en statique soit la packager pour tous les OS cibles... mmh bon finalement je vais réinventer les algos qui m'intéressent et hop.
Tout à fait d'accord sur ce point. Et oui les package manager des OS ne sont pas non plus des solutions à ces problèmes.
Ceci dit, réimplémenter la roue dans chaque langage et shipper ses propres libs systèmes dans chaque pseudo-build système / package manager langage spécifique n'est pas non-plus une solution.
Dans le monde idéal, je veux pouvoir déployer mon module C++ utilisé par un interpréteur python accompagné d'un petit service Java et d'un tool en Haskell sans avoir à :
jongler entre le pip de python qui n'aime pas les libs binaires car c'est pas son job
Conan de C++ qui n'aime pas JAVA car c'est pas son job
Maven qui n'aime pas python parce qu'il a été marié à Java
Et cabal de Haskell qui ne s'aime même pas lui même.
Et j'ai volontairement laissé npm en dehors de l'histoire d'eviter le troll trop facile.
[^] # Re: Par Crom, il faut un maven pour C++ !
Posté par Firwen (site web personnel) . En réponse au journal Un petit tour des systèmes de build. Évalué à 5. Dernière modification le 18 juin 2018 à 14:50.
Tout à fait d'accord sur ce point. Et oui les package manager des OS ne sont pas non plus des solutions à ces problèmes.
Ceci dit, réimplémenter la roue dans chaque langage et shipper ses propres libs systèmes dans chaque pseudo-build système / package manager langage spécifique n'est pas non-plus une solution.
Dans le monde idéal, je veux pouvoir déployer mon module C++ utilisé par un interpréteur python accompagné d'un petit service Java et d'un tool en Haskell sans avoir à :
Et j'ai volontairement laissé npm en dehors de l'histoire d'eviter le troll trop facile.