Куда мне поместить сторонние библиотеки?
Я участвую в проекте C ++ приличного размера с рядом зависимостей. Проблема в том, что проект содержит источник всех своих зависимостей (например, pcre, zlib и т. Д.). Я хочу урезать проект до того, что имеет отношение к самой программе. Есть ли какой-то относительно стандартный способ компиляции этих библиотек и их размещения где-нибудь, и чтобы их заголовочные файлы также были легко доступны?
Для чего стоит я использую Windows 7, и я разрабатываю с использованием VS2005. Я также полный нуб с работой над большими проектами C ++ на Windows; Мне никогда не приходилось выходить за пределы стандартной библиотеки и win32.
3 ответа
Структура, которую мы используем на моем рабочем месте, имеет одну папку «Внешняя», которая содержит папку «Включить» и папку «Библиотека» для заголовков и внешних библиотек. Однако, поскольку мы также используем VS, мы стараемся максимально использовать его функцию «Зависимости», удаляя ручной ввод в компоновщик. Это означает, что в папку «Внешняя» попадают только проекты, которые не находятся в одном и том же решении. Кроме того, поскольку у нас есть некоторые сторонние библиотеки, специфичные для некоторых проектов, мы создаем папки внутри папки проекта для этих включений и библиотек. Вот как это получается:
.\ |-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
Я не могу сказать, является ли это лучшей структурой, но все находится под управлением исходного кода, мы можем выполнять ночные сборки, просто собирая решение, а разработка идет путем создания отдельных проектов.
В вашем утверждении есть ошибка: «Я хочу сократить проект до того, что имеет отношение к самой программе».
Поверьте мне, зависимости чрезвычайно важны для программы. Если у вас их нет в системе управления версиями, вы столкнетесь с бесконечными проблемами при представлении новых членов команды или при переключении на новую рабочую станцию.
Даже если скомпилировать «нерелевантные» библиотеки, эти скомпилированные библиотеки должны попасть в ваш исходный репозиторий.
Я видел, как группы делали следующее:
- Отделяли внутренний код от внешнего (код, который они создали, от кода внешних компаний)
- Отделяли свой код от кода библиотеки
- Отделяли каждый программа и каждая библиотека
- Проверьте скомпилированную версию своих зависимостей, чтобы она не была частью их полного цикла сборки (по крайней мере, не в некоторых ветках. Другие ветки могут выполнять более полную сборку)
Проекты существовал для каждого exe или библиотеки в каталоге с файлом exe/library.
Решения существовали везде, где команды считали это полезным, и двоичные файлы часто связывались, а не их проекты включались в подрешения. Только полная сборка гарантировала, что не сломается при свежем зачислении.
Предупреждение о возврате...