Comment gérer correctement les dépendances pour un projet C / C ++?

J'ai un projet qui utilise 3-4 différentes bibliothèques C / C ++ open source.

J'ai construit ces bibliothèques pour plusieurs plates-formes et archivé des fichiers et des bibliothèques statiques pour différentes plates-formes dans mon projet.

Cependant, je lutte avec quelques problèmes. Tous ces projets concernent la gestion des dépendances. Et je recherche des conseils sur les meilleures pratiques.

1) Comment savoir exactement ce que j'utilise?

Je n'ai aucun moyen d'obtenir une version d'une bibliothèque statique. Par conséquent, j'ai besoin de suivre en quelque sorte la version de la bibliothèque statique que j'utilise (peut-être SHA d'un commit à partir duquel il a été construit)?

Ceci est particulièrement important lorsque j'ai besoin de savoir quand mettre à niveau ces bibliothèques.

2) Comment reproduire la version?

J'aurais pu avoir du mal à construire une bibliothèque spécifique pour une plate-forme spécifique. Il m'a fallu un certain temps pour le comprendre.

La prochaine fois que j'aurai besoin de construire la même bibliothèque pourrait être dans un semestre (quand j'aurai besoin de mettre à niveau pour une raison quelconque. Cependant, d'ici là, je ne me souviendrai définitivement de rien et d'un environnement sur lequel elle a été construite sera disparu depuis longtemps.

3) Dois-je bifurquer ces bibliothèques pour avoir une copie du code source?

C'est une préoccupation moindre. Cependant, c'est toujours une préoccupation. Il est agréable de s'assurer que les versions sont reproductibles (et que ce type de code nécessite du code source).

Avez-vous vraiment besoin de toujours utiliser une version exacte d'une bibliothèque dépendante? Est-il mal écrit / casse-t-il son API à chaque augmentation mineure de version?

Si vous regardez des projets open-source, leurs configurescripts de construction (en partie principalement) vérifient si diverses bibliothèques sont présentes et génèrent une erreur sinon. Il est également suffisamment flexible pour permettre à l'utilisateur de se lier à une version plus récente de la bibliothèque (qui fournit probablement plus de correctifs de bogues / de sécurité qu'une ancienne) et n'applique pas non plus la liaison statique ou dynamique.

Si vous avez vraiment besoin de versions reproductibles, vous devez également faire attention à la version exacte du compilateur et à ses bibliothèques standard, peut-être même au système d'exploitation. Dans ce cas, avoir une machine de construction avec l'environnement exact dont vous avez besoin est, à mon avis, mieux que d'archiver les bibliothèques compilées dans le référentiel de code source.

Comment savoir exactement ce que j'utilise?

Si les fichiers include ou libs ne contiennent pas déjà de numéro de version, ajoutez vous-même un fichier texte "version.txt" (contenant le numéro de version) dans chaque dossier lib et archivez-le dans votre VCS, avec les fichiers lib et include . Cependant, si vous versionnez la source complète de la lib (point 3), il y a de fortes chances qu'il existe déjà un fichier de code source contenant le numéro de version, donc pas besoin de maintenir le vôtre dans ce cas.

Comment reproduire la build?

Essayez d'automatiser autant que possible. Utilisez des scripts, des makefiles ou des fichiers de vos outils de construction préférés. Mettez tout cela sous contrôle de source. Si des étapes manuelles sont requises, écrivez les détails dans un fichier texte (par exemple, readme_build.txt) et placez-le également sous contrôle de source.

Dois-je bifurquer ces bibliothèques pour avoir une copie du code source?

Vous devriez avoir une copie du code source , mais ne forkez que si nécessaire (par exemple, si vous tombez sur un bogue urgent et que l'auteur d'origine ne peut pas le corriger dans les limites de votre temps). Ou, si les auteurs utilisent un environnement de compilateur différent de vous, et qu'il est nécessaire de faire quelques changements pour que la lib fonctionne dans votre environnement. Cependant, sachez que chaque modification du code source d'origine dans votre fork rend très probablement plus difficile l'intégration des mises à jour ultérieurement.

Néanmoins, je recommande d'obtenir une copie du code source original (non modifié) des bibliothèques que vous utilisez. Cela vous permettra de bifurquer ou de maintenir la lib plus tard si cela devient nécessaire, même si le mainteneur d'origine décide de révoquer les sources de lib du web public.