Управление пакетами для переполнения стека
Я работаю в компании, которая разрабатывает проект, разделенный на компоненты, которые разрабатываются разными группами разработчиков. Все в C ++.
Они используют много общих библиотек, и для управления ими они создали инструмент, который каким-то образом связывает версию проекта и версии библиотек.
Речь идет о существовании некоторого инструмента на рынке, который уже делает это:
Я имею в виду, что если я пойду к этому инструменту, я могу загрузить, например, версию 4.0 нашего проекта, которая имеет точно версию 4.5 библиотеки 1 и 3.4 библиотеки 2. Если я нажму «Скачать», я буду загружать исходный код (или двоичный код) этого все (проект + библиотеки) проект и конкретная версия каждой библиотеки.
Например, если я хочу скачать другой проект других разработчиков в компании, используя одни и те же библиотеки в другой версии или на разных платформах, мне нужно только выбрать это, и я собираюсь загрузить проект 2 с библиотекой 1 версии 5.0 и библиотекой 2 2.5, и так далее. на.
Есть ли на рынке какой-либо инструмент, который позволяет мне создавать такие отношения, и, между прочим, соединяется с репо кода (в нашем случае это gitlab)?
Я проверил Gradle, Conan, … но они строят, а не управляют «отношениями» между компонентами.
Что-то вроде того:
Решение
CMake обеспечивает достаточную функциональность для создания подобных отношений в вашей системе сборки. К сожалению, вы должны использовать CMake для управления сборками для всех ваших проектов, чтобы это работало хорошо. CMake работает с Visual Studio, а также с GCC, Clang и ICC. Если это вас интересует, продолжайте читать.
- использование CMake построить конфигурации сборки для ваших зависимых проектов.
- использование ExternalProject Команды для выражения зависимостей родительских проектов.
- ExternalProject поддерживает Git, а также Mecurial, CSV, SVN и прямые загрузки tar-архивов.
- Вы можете указать точную фиксацию, тег или ветку в Git.
- Поддерживает аутентификацию Git через SSL или Basic HTTP.
- Запустите CMake для родительского проекта. Все зависимости загружаются и компилируются автоматически.
Пример зависимости
ExternalProject_Add(
Library1
GIT_REPOSITORY https://[email protected]/repo/library_1.git
GIT_TAG tag_S.33.91
HTTP_USERNAME ciserv
HTTP_PASSWORD Obfusc@t3M3
CMAKE_ARGS
-DBUILD_EXAMPLES:BOOL=OFF
-DBUILD_TESTS:BOOL=OFF
-DBUILD_DOCS:BOOL=OFF
)
target_link_libraries(MyTarget PRIVATE Library1)
В модуле ExternalProject есть несколько других команд, которые можно использовать для дальнейшей настройки зависимости, если это необходимо.
Другие решения
Чтобы продолжить ответ @ norman-b-lancaster, подумайте о Менеджер пакетов Hunter. Он основан на функции ExternalProject CMake и в значительной степени ориентирован на воспроизводимые сборки. Каждый выпуск Hunter предоставляет сценарий CMake, необходимый для блокировки версий пакетов всех зависимостей.
Ваш вопрос предполагает, что вы обеспокоены управлением пакетами в вашей компании (в отличие от общедоступных пакетов от ex: GitHub). Сопровождающие охотника знают о Эта проблема и, кажется, открыт для поддержки, если спрос есть.
Есть cget это позволяет установить зависимость, просто указав на исходный архив, который предоставляют такие хостинговые сервисы, как github и gitlab. Вы также можете предоставить requirements.txt установить все зависимости также транзитивно.
Он основан на cmake, который будет устанавливаться с небольшими изменениями, но также поддерживает другие не-cmake пакеты. Вы также можете создать дистрибутив рецепты для обработки пакетов, которые не соответствуют стандартному рабочему процессу настройки, сборки и установки. Существует также множество рецептов, уже доступных для многих проектов C ++. Вот.