управление библиотечными зависимостями с помощью Boost.Build и Stack Overflow
Я хочу разработать проект, который может быть построен на множестве разных платформ.
Код проекта будет на C ++, как лучше всего управлять библиотеками?
Я планирую использовать bjam в качестве системы сборки, потому что я буду зависеть от Boost и их среды модульного тестирования.
Две зависимости — это Boost само по себе и FLTK.
Возможности, которые приходят на ум для управления библиотекой:
- включить в сборку артефакты (двоичные файлы) и заголовки для всех поддерживаемых платформ
- включить полный исходный код для всех библиотечных зависимостей в дерево и каким-то образом записать их как зависимости
- Комбинация 1 и 2, как node.js делает с v8
- проинформируйте пользователя, что ему нужно собрать библиотеки самостоятельно, а затем поместить их в PATH или в какой-то специальный каталог, как это делает libcurl со своими зависимостями
- зависит от стиля сборки * nix (т.е. libtool) в стиле mozilla, а затем сообщает пользователю, что он должен использовать MSYS для сборки на windows
Каков наилучший подход здесь?
Проект, вероятно, не вырастет за несколько тысяч строк в течение следующих шести месяцев, но я хочу сделать право выбор здесь, так что мне не придется возвращаться и все поменять позже.
Решение
Это субъективный ответ.
Во-первых, о Boost: после того, как Boost собран, вам не нужно использовать bjam. Поэтому вы можете использовать любую подходящую вам систему сборки, требуя наличия определенных библиотек в системе или по определенным путям, какими бы они ни были собраны. В качестве дополнительного примечания, большая часть надстройки — только заголовки (даже в модуле модульного тестирования может использоваться только заголовок IIRC, но рекомендуется использовать версию библиотеки). Предположим, вам нужны бинарные файлы.
Лучший способ справиться с проектом IMO — это использовать выбранную вами систему сборки, которая больше всего подходит вам для вашего собственного проекта, и требует, чтобы зависимости (повышенные) были «предварительно собраны». Как они построены, зависит от каждой зависимости; некоторые могут использовать ту же систему сборки, которую вы выберете, другие будут использовать свои собственные системы сборки. Некоторые будут сделаны для всех платформ, и, например, некоторые будут компилироваться на Windows, но не будут иметь лучшей системы сборки, подходящей для Windows. Если это небольшие библиотеки, вы можете интегрировать их в свою систему сборки, в противном случае просто подумайте о них как о «зависимости», которую разработчик «каким-то образом» должен будет иметь перед сборкой вашего проекта. «Как-то» здесь должно быть объяснено в README.
Так, например, я использую cmake для своего проекта, но использую boost и несколько других библиотек в моем проекте. cmake позволяет мне создавать файлы проекта для MSVC, C :: B, GNUMake и т. д., но я не могу надеяться, что все мои зависимости будут также использовать cmake. Для очень маленьких, стабильных библиотек я могу сделать для них проект cmake, и тогда все будет действительно просто. Для больших или более изменчивых библиотек лучше оставить каждую собственную систему сборки. Изменчивые библиотеки часто меняются, поэтому, если вы создадите для них что-то «нестандартное», вам придется постоянно адаптировать свои «настройки» к изменениям в библиотеке. Для каждой библиотеки, которую я использую, у меня есть некоторая переменная cmake, такая как BOOST_LIB_INCLUDE_PATHS и BOOST_LIB_LIBRARY_PATHS и BOOST_LIB_LIBRARIES, которые могут быть определены по их значениям разработчиком, компилирующим мой проект. cmake предоставляет некоторые возможности поиска в магической библиотеке, но я обнаружил, что такая магия — отвратительные хаки, поэтому я явно требую, чтобы пути были заданы как переменные.
Вы можете сами решить, следует ли предоставлять источники для этих библиотек; в этом нет ничего плохого, особенно если вы хотите зависеть от конкретной версии библиотеки. Но сценарии их как зависимости могут стать большим беспорядком, помимо обслуживания для изменчивых библиотек.
Тем не менее, я знаю, когда проект Google Chromium создается, загружается, проверяется, создается и связывается что-то около ста библиотек. Chromium использует GYP в качестве системы сборки IIRC.
Другие решения
Других решений пока нет …