Quelle est la bonne façon d'ajouter du code tiers dans un projet C ou C ++?
Je veux incorporer quelques bibliothèques open source dans mon projet C. C'est la première fois que je fais ça, donc je ne sais pas quelle est la bonne façon ou la façon la plus courante de le faire.
Je vois deux chemins possibles que je peux emprunter:
- Téléchargez le code de chaque bibliothèque que j'utiliserai, ajoutez-les à mon dossier de projet et modifiez-les selon mes besoins.
- Répertoriez simplement chaque bibliothèque en tant que dépendance. Ainsi, l'utilisateur les téléchargerait sur sa machine et les inclurait dans le projet avec (peut-être) une configuration de makefile.
Je pense que l'option # 1 est meilleure pour deux raisons:
- Je libère l'utilisateur de la tâche de téléchargement et de configuration de la dépendance.
- Dans mon projet, deux bibliothèques ont du code qui se chevauchent. Une partie d'une bibliothèque est un sous-ensemble de l'autre. Ils ont les mêmes fonctionnalités et les mêmes identifiants (variables, fonctions, #defines). J'aurais donc des conflits que je ne sais pas comment résoudre.
Mais je pensez juste l'option # 1 est meilleure. Je ne sais vraiment pas quel est le meilleur. Peut-être que quelqu'un sait comment résoudre les conflits entre les bibliothèques et que mon opinion pourrait changer. Je pose cette question parce que je ne sais pas quel chemin les programmeurs empruntent habituellement. Je ne sais pas non plus quels sont les avantages et les inconvénients de chaque alternative. Et je ne sais pas non plus s'il existe d'autres alternatives.
pdate: Les utilisateurs attendus sont des programmeurs.
@ 17of26 a donné beaucoup de bonnes raisons pour lesquelles # 2 est dangereux, et pourquoi # 1 est plus logique. Mais je pense qu'il manque une chose, pour laquelle je recommande ce qui suit:
- téléchargez le code de la bibliothèque que vous utiliserez,
- ajoutez-le au dossier du projet,
- mais ne le modifiez pas arbitrairement !!
Évitez si possible les modifications. Si ce n'est pas possible, essayez de limiter au minimum les modifications directes et de conserver tout le reste dans des fichiers séparés. Si nécessaire, utilisez des fichiers de script ou des fichiers de correctifs. Assurez-vous donc que toutes les modifications apportées aux bibliothèques ou à la configuration du makefile sont documentées et peuvent être reproduites.
Cela vous donne une meilleure chance de mettre à jour vers des versions plus récentes de ces bibliothèques à un moment ultérieur, si nécessaire.
Bien sûr, il n'y aura aucune garantie que les correctifs ou les changements de configuration appliqués à la version 1.0 d'une lib peuvent également être appliqués directement à la version 2.0 de cette lib. Mais les chances sont d'autant plus élevées qu'il n'y a que quelques correctifs/modifications, et l'effort de les appliquer sera probablement moindre.
Vous voulez toujours empaqueter toutes les dépendances avec votre projet.
Votre logiciel va être construit et testé avec une version particulière d'une bibliothèque spécifique. Il n'est pas garanti de fonctionner avec une autre version.
Vous devez envoyer votre code avec cette version exacte de la bibliothèque. Si vous ne le faites pas, vous ouvrez la porte à un cauchemar de soutien.
Par exemple, disons que vous construisez et testez votre code avec la bibliothèque Foo v1.0. Vous ne livrez pas Foo v1.0 avec votre produit et dites plutôt "Hé les utilisateurs, allez chercher cette bibliothèque Foo v1.0".
Imaginez maintenant:
- Foo disparaît d'Internet. Il est peut-être hébergé par une entreprise qui fait faillite. Ou peut-être que le développeur de Foo v1.0 en a assez des courriels d'utilisateurs en colère et supprime l'accès public à la bibliothèque.
- Foo est développé très activement. Foo est maintenant sur v8.0. Le développeur Foo décide d'arrêter de prendre en charge tout ce qui est plus ancien que la v7.0 et supprime l'accès aux versions antérieures.
- Le développeur Foo apporte un changement de rupture à la v1.0 mais n'incrémente pas réellement la version. Maintenant, lorsque les utilisateurs téléchargent la version 1.0, ils obtiennent une bibliothèque différente de celle que vous avez utilisée et cela ne fonctionne tout simplement pas.
Vous évitez tous ces maux de tête potentiels en expédiant les binaires exacts dont le logiciel a besoin pour fonctionner.
Une manière courante de gérer le code tiers est via les "branches du fournisseur" (je suppose que vous utilisez une sorte de système de contrôle de version tel que git, svn, etc.).
Les succursales des fournisseurs vous permettent de suivre les modifications apportées au code tiers et d'incorporer facilement ces modifications dans votre code ainsi que toutes les modifications que vous devez apporter à votre code pour travailler avec ces modifications.
Le sujet des branches de fournisseurs est trop compliqué pour être abordé ici (et les détails dépendraient des vcs que vous utilisez), mais il existe de nombreux guides utiles sur le Web.