Un peu de tout

J'arrive un peu tard mais je participe quand même.

Alors, s'il vous plaît, dites moi comment vous faites pour échapper à l'enfer des dépendances.

Sur mes petits projets il y a peu de dépendances et pas de conflit de versions. Je prend donc ce qui est disponible sur le système ou alors je compile et j'installe dans ~/.local/. Pendant un moment je m'embêtais à gérer dans mes CMakeLists.txt la possibilité d'utiliser la version locale ou de télécharger la dépendance via FetchContent. C'était une très mauvaise idée, ça fait plein de cas à gérer et amène trop de questions. Du coup maintenant c'est seulement du local, beaucoup plus simple.

Au boulot on a des tonnes et des tonnes de dépendances. Du coup on fait des RPM pour chaque, et je suis bien content de ne pas m'en occuper. Parmi les trucs qui m'embêtent il y a le problème que lorsqu'on modifie une dépendance il faut refaire les RPMs pour toute la chaîne jusqu'au produit pour pouvoir enfin tester, voir qu'on a oublié un truc, re-patcher la dépendance, et recommencer. L'autre souci est que ça devient tellement gros que ça bloque tout le monde sur une distribution donnée. Du coup si t'es sous Windows, ou sous un Linux non corporate, il te faut une VM Linux, ou un Docker, avec la distrib' officielle pour pouvoir travailler. C'est un vrai frein au quotidien, tous les outils deviennent dépassés hyper vite.

Avant ça dans une autre boîte sur un projet plus petit et une petite équipe j'avais pris une approche à base de script. Pour donner une idée de l'échelle, nous étions trois développeurs au maximum et il y avait une petite quarantaine de dépendances. En gros ça ressemblait à ça :

• Du côté du produit final, on avait un fichier listant les dépendances selon la plate-forme ciblée (Android, iOS, OSX, Linux), et un script qui récupérait les dépendances pour les mettre dans un dossier .local du build. Les dépendances pouvaient être des bibliothèques ou des outils de build (par exemple le SDK Android). Les dépendances étaient récupérées au choix uniquement localement ou alors depuis un bucket S3. Il faut voir le dossier .local comme un / dans lequel les dépendances étaient cherchées par le système de build.
• Pour la construction des dépendances on avait un lot de scripts outils et d'autres scripts qui utilisaient ces outils pour faire des archives prêtes à être consommées par le produit. Certaines dépendances étaient des binaires fournis par divers services (par exemple des .framework de régies pub pour iOS), auquel cas on les rangeait juste dans un dossier pratique dans le faux /. D'autres dépendances étaient compilées, installées dans un dossier temporaire puis archivées pour être prêtes à être mises telles quelles dans le faux /.

Dans les aspects bien pratiques :

• chaque développeur pouvait compiler les dépendances nativement pour son système,
• on pouvait surcharger les dépôts des dépendances pour cibler nos dépôts locaux, et ainsi tester des modifs sur des dépendances sans reboucler par le central,
• le build était isolé, pas autant que dans un Docker ou un fakeroot mais suffisamment pour nous,
• les outils de build faisaient partie des dépendances (on avait besoin que de bash, sed, grep, tar, et un compilateur pour lancer le tout, et encore ce dernier pouvait faire partie des dépendances).

Dans les aspects pas pratiques :

• le code des scripts outils n'étaient pas très accueillants pour ceux qui ne sont pas à l'aise en Bash,
• j'aurais dû faire ça en Python pour que ça fonctionne sous Windows (mais en même temps ça demande d'avoir un Python d'installé et on revient au problème du journal ; et puis personne n'utilisait du Windows),
• on a eu quelques mauvaises surprises de link en utilisant sur un système des dépendances compilées sur un autre système,
• je suis quasi sûr que ça ne scale pas avec de plus grandes équipes ou plus de dépendances.

De mon côté je n'ai jamais utilisé Conan ou vcpkg et je me demande si ces outils auraient permis d'installer des dépendances d'outils de build telles que le SDK Android ou autres outils. Ou encore de construire les dépendances à partir de dépôts locaux. Concernant l'intégration dans les outils de build, je ne vois pas trop comment on pourrait par exemple lancer CMake en ciblant Android tout en essayant de récupérer le SDK via Conan intégré à CMake. Ça se mort la queue. Pour moi l'installation des dépendances se fait forcément en amont de la configuration du build. Donc forcément il y a un peu de scripting.