C'est une problématique très intéressante que tu soulèves ici.
Malheureusement, les gens soucieux de ces problèmes se soucient en général simplement des versions de librairies utilisées (que ce soit en C/C++ ou même d'autres langages). Alors qu'en pratique, ton compilateur et tous les outils de ta toolchain sont aussi importants. Pour moi la reproductibilité implique de recréer le même binaire au bit près, pas de s'assurer des dépendances sur des librairies.
Dans ma dernière expérience professionnelle sur le sujet, j'avais mis en place une forme de conteneur léger (à coup de chroot) basée sur debian testing, avec génération automatique chaque semaine ou quand besoin d'une nouvelle lib/version de compilo. Le tout rapatrié avec rsync via ssh. Sinon possib de monter tout le bouzin via NFS mais c'était trop chiant en infra pour nous. Ça offrait une belle portabilité peu importe la distribution linux utilisée par les collègues (et simplifie l'intégration continue accessoirement). Quant à l'arrivée d'un nouveau, il suffit de faire: git clone && get_env.sh && make. Simple et efficace au possible. Il me restait, mais je ne l'ai pas fait, à "versionner" cet environnement de build (qui est une chose très importante aussi). Pour cela, un montage BtrFS avec snapshots permet de faire un stockage incrémental (on ne stocke que les diffs) et adapté. Reste à ajouter un hash quelque part et pointer sur le bon dans ton code, et tu as un environnement de build complètement déterministe, mais pour Linux uniquement. Un jour si je me motive, faudrait que je package et publie le tout, je suis sûr que ça pourrait attirer du monde. Bien plus qu'une solution bricolage comme Biicode (c'est mon humble avis).
Il reste le problème de la cross compilation. MacOS ne m'intéresse pas d'un iota. Pour les BSDs un cross compilo fait le taff. Quant à Windows, soit tu peux cross compiler un gcc, soit, une autre approche que j'avais tenté sur mon temps libre, c'est d'utiliser le compilo de visual (cl.exe) via wine (et pas visual lui même). Ça fonctionne rudement bien (modulo des variables d'env à setter) et si je devais m'occuper de ça un jour, ce serait ma voie d'approche. Avec le wine dans l'env de build décrit au-dessus, tu obtiens une solution déterministe pour le build Linux/Windows depuis toute version/distrib de Linux.
Une fois cela fait, un travail important reste de packager toi-même toutes les librairies dont tu dépends. Chez nous, on s'en était assez facilement sorti avec un peu de script.
Cette façon d'approcher, reste, je pense, la plus simple et efficace. Des collègues plutôt orientés Java m'ont montré Nexus et le concept d'artifact repository. Pour moi, ça revient à de la gestion de libs, le tout dans une belle usine à gaz webistique. J'imagine que ça dépend des goûts de chacun, moi je n'ai pas accroché en tout cas...
[^] # Re: Sa conclusion : on a besoin d'un gestionnaire de dépendance pour C/C++
Posté par Pierrick Bouvier . En réponse au journal Adieu Biicode, bonjour Conan. Évalué à 3.
C'est une problématique très intéressante que tu soulèves ici.
Malheureusement, les gens soucieux de ces problèmes se soucient en général simplement des versions de librairies utilisées (que ce soit en C/C++ ou même d'autres langages). Alors qu'en pratique, ton compilateur et tous les outils de ta toolchain sont aussi importants. Pour moi la reproductibilité implique de recréer le même binaire au bit près, pas de s'assurer des dépendances sur des librairies.
Dans ma dernière expérience professionnelle sur le sujet, j'avais mis en place une forme de conteneur léger (à coup de chroot) basée sur debian testing, avec génération automatique chaque semaine ou quand besoin d'une nouvelle lib/version de compilo. Le tout rapatrié avec rsync via ssh. Sinon possib de monter tout le bouzin via NFS mais c'était trop chiant en infra pour nous. Ça offrait une belle portabilité peu importe la distribution linux utilisée par les collègues (et simplifie l'intégration continue accessoirement). Quant à l'arrivée d'un nouveau, il suffit de faire: git clone && get_env.sh && make. Simple et efficace au possible. Il me restait, mais je ne l'ai pas fait, à "versionner" cet environnement de build (qui est une chose très importante aussi). Pour cela, un montage BtrFS avec snapshots permet de faire un stockage incrémental (on ne stocke que les diffs) et adapté. Reste à ajouter un hash quelque part et pointer sur le bon dans ton code, et tu as un environnement de build complètement déterministe, mais pour Linux uniquement. Un jour si je me motive, faudrait que je package et publie le tout, je suis sûr que ça pourrait attirer du monde. Bien plus qu'une solution bricolage comme Biicode (c'est mon humble avis).
Il reste le problème de la cross compilation. MacOS ne m'intéresse pas d'un iota. Pour les BSDs un cross compilo fait le taff. Quant à Windows, soit tu peux cross compiler un gcc, soit, une autre approche que j'avais tenté sur mon temps libre, c'est d'utiliser le compilo de visual (cl.exe) via wine (et pas visual lui même). Ça fonctionne rudement bien (modulo des variables d'env à setter) et si je devais m'occuper de ça un jour, ce serait ma voie d'approche. Avec le wine dans l'env de build décrit au-dessus, tu obtiens une solution déterministe pour le build Linux/Windows depuis toute version/distrib de Linux.
Une fois cela fait, un travail important reste de packager toi-même toutes les librairies dont tu dépends. Chez nous, on s'en était assez facilement sorti avec un peu de script.
Cette façon d'approcher, reste, je pense, la plus simple et efficace. Des collègues plutôt orientés Java m'ont montré Nexus et le concept d'artifact repository. Pour moi, ça revient à de la gestion de libs, le tout dans une belle usine à gaz webistique. J'imagine que ça dépend des goûts de chacun, moi je n'ai pas accroché en tout cas...