Где я должен размещать сторонние библиотеки?

Я вношу вклад в проект С++ с приличным размером с несколькими зависимостями. Проблема заключается в том, что проект содержит источник всех его зависимостей (например, pcre, zlib и т.д.). Я хочу подрезать проект до самого важного для самой программы. Есть ли относительно стандартный способ скомпилировать эти библиотеки и поместить их где-нибудь, а также легко получить их файлы заголовков?

Для чего это стоит, я использую Windows 7, и я разрабатываю VS2005. Я также полный noob, работая над большими проектами на С++ в Windows; Мне никогда не нужно было выходить за пределы стандартной библиотеки и win32.

ОТВЕТЫ

Ответ 1

Структура, которую мы используем на моем рабочем месте, имеет одну "внешнюю" папку, содержащую папку "Include" и "Lib" для заголовков и внешних Lib. Однако, поскольку мы также используем VS, мы стараемся как можно больше использовать функцию "Зависимости", удаляя ручные входы в компоновщик. Это означает, что только проекты, которые не находятся под одним и тем же решением, попадают в папку "External". Кроме того, поскольку у нас есть некоторые сторонние библиотеки, специфичные для некоторых проектов, мы создаем папки внутри папки проекта для этих включений и libs. Вот как это получается:

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

Я не могу сказать, является ли это лучшей структурой когда-либо, но все находится под контролем источника, мы можем делать ночные сборки только путем создания решения, а разработка идет путем создания отдельных проектов.

Ответ 2

В вашем заявлении есть ошибка: "Я хочу подрезать проект до того, что относится к самой программе".

Поверьте, зависимости чрезвычайно важны для программы. Если у вас их нет в исходном управлении, вы не столкнетесь с проблемами при вводе новых членов команды или при переключении на новую рабочую станцию.

Даже если компилировать "не относящиеся к делу" библиотеки, эти скомпилированные библиотеки должны попасть в ваш исходный репозиторий.

Ответ 3

Я видел, что группы делают следующее:

  • Отделите внутренний код от внешнего кода (код, который они сделали против внешних компаний)
  • Отделите свой код от кода библиотеки
  • Отделить каждую программу и каждую библиотеку
  • Проверьте скомпилированную версию своих зависимостей, поэтому она не является частью их полного цикла сборки (по крайней мере, не в некоторых ветвях. Другие ветки могут сделать более полную сборку)

Проекты существовали для каждого exe или библиотеки, в каталоге с exe/library.

Решения существовали везде, где команды чувствовали, что это было бы полезно, и бинарные файлы часто связывались, а не их проекты, включенные в подрешения. Было гарантировано, что только полная сборка не будет разорвать новый призыв.

Предостережение emptor...