Où dois-je mettre les bibliothèques tierces?

Question

Je contribue à un decent-sized C++ project avec un certain nombre de dépendances. Le problème est que le projet contient la source de toutes ses dépendances (par exemple pcre, zlib, etc.). Je veux réduire le projet à ce qui est pertinent pour le programme lui-même. Existe-t-il un moyen relativement standard de compiler ces bibliothèques et de les mettre quelque part, et d'avoir leurs fichiers d'en-tête aussi facilement accessibles?

Pour ce que ça vaut, j'utilise Windows 7, et je développe en utilisant VS2005. Je suis également un expert complet pour travailler sur de grands projets C++ sous Windows; Je n'ai jamais vraiment eu besoin de sortir de la bibliothèque standard et win32.

Answer 1

Une structure que nous utilisons sur mon lieu de travail est d'avoir un dossier « externe » qui contient un dossier « Inclure » et un « Lib » pour les en-têtes et les bibliothèques externes. Cependant, comme nous utilisons aussi VS, nous essayons d'utiliser le plus possible sa fonction "Dépendances", supprimant les entrées manuelles dans l'éditeur de liens. Cela signifie que seuls les projets qui ne sont pas sous la même solution vont dans le dossier "Externe". De plus, comme nous avons des bibliothèques tierces spécifiques à certains projets, nous créons des dossiers dans le dossier du projet pour ces includes et libs. Voici comment il obtient:

 
.\ 
|-Project1\ --> contains Project1.vcproj 
|-Project2\ --> contains Project2.vcproj 
| |-Third-Party\ 
| |-Include\ 
| |-Lib\ 
|-External\ 
| |-Include\ 
| |-Lib\ 
|-InternalLibrary\ --> contains InternalLibrary.vcproj 
|-Solution.sln --> includes the vcproj's and link them as necessary by its dependencies 

Je ne peux pas dire si cela est la meilleure structure jamais, mais tout est sous contrôle de code source, nous pouvons faire la nuit construit juste en construisant la solution, et le développement va en construisant unique projets.

Answer 2

Il y a une erreur dans votre déclaration: «Je veux réduire le projet à ce qui est pertinent pour le programme lui-même." Croyez-moi, les dépendances sont extrêmement pertinentes pour le programme. Si vous ne les avez pas dans le contrôle des sources, vous ne rencontrerez pas de fin de problèmes lors de l'introduction de nouveaux membres de l'équipe ou lors du passage à un nouveau poste de travail.

Même si vous compilez les bibliothèques "non-pertinentes", ces bibliothèques compilées devraient aller dans votre référentiel source.

Answer 3

J'ai des groupes vus effectuer les tâches suivantes:

• code interne séparé de code externe (code qu'ils ont fait contre des sociétés externes)
• séparé leur code à partir de la bibliothèque
• séparée de chaque programme et chaque bibliothèque
• Archivez une version compilée de leurs dépendances, de sorte qu'elle ne fasse pas partie de leur cycle de construction complet (au moins, pas dans certaines branches.) Les autres branches peuvent effectuer une construction plus complète)

Des projets existaient pour chaque exe ou bibliothèque, dans le répertoire avec l'exe/bibliothèque.

Des solutions existaient partout où les équipes pensaient que cela serait bénéfique, et les binaires étaient souvent liés, plutôt que leurs projets inclus dans les sous-solutions. Seule une construction complète était garantie de ne pas rompre avec un nouvel engagement.

caveat emptor ...