Управление версиями общей библиотеки с помощью cmake на github

У меня есть довольно новый проект на github, который создает общую библиотеку. В дальнейшем я хотел бы использовать семантическое управление версиями (как описано на semver.org) для основной / второстепенной общей библиотеки. / номера патчей в имени файла. В проекте используется CMake. Файл CMakeLists.txt ссылается на CPACK_PACKAGE_VERSION_MAJOR, CPACK_PACKAGE_VERSION_MINOR и CPACK_PACKAGE_VERSION_PATCH и устанавливает для них значения по умолчанию, если они не передаются в командной строке.

Я планирую перейти к изменениям ABI и добавлениям API в соответствии с принципами семантического управления версиями.

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

Например, если у меня есть ветка myproj_1_2 и тег выпуска myproj_rel_1_2_9, есть ли способ, чтобы общая библиотека, созданная пользователем, имела имя libmyproj.so.1.2.9?

Это просто вопрос документирования того, что пользователь должен передать информацию об имени сборки в командной строке cmake, а файл CMakeLists.txt проанализирует это и установит CPACK_PACKAGE_VERSION_MAJOR, CPACK_PACKAGE_VERSION_MINOR и CPACK_PACKAGE_VERSION_PATCH соответственно, или есть более элегантный способ сделать это?


github linux cmake semantic-versioning shared-libraries
person ChrisF    schedule 30.11.2018    source источник
comment
Никакие два набора битов никогда не должны иметь одинаковое имя и номера версий, если какое-либо их содержимое отличается хотя бы на один бит. Большинство систем сборки неспособны производить точно такие же входные данные из одного и того же исходного кода, когда имена пользователей / компьютеров, корневые пути или время начала / окончания меняются ...   -  person jwdonahue    schedule 01.12.2018
comment
Поэтому глупо пытаться согласованно управлять версиями выходных данных для пользователей, компьютеров, корневых путей и времени запуска / остановки, которое не включает криптографически безопасный хэш всех входных данных, в том числе; пути пользователя, компьютера, корневого каталога, время запуска / остановки и любые другие неисчислимые причины, по которым системы сборки дают недетерминированные результаты.   -  person jwdonahue    schedule 01.12.2018
comment
‹Opinion› Только официальные системы сборки должны иметь право производить все, что выглядит как окончательная версия! ‹/Opinion›. Самый простой способ - всегда принудительно использовать предварительный тег или использовать 0.0.0. Официальные сборки добавили бы дополнительный шаг копирования / переименования библиотеки.   -  person jwdonahue    schedule 01.12.2018

Ответы (1)


arrow_upward
2
arrow_downward

Ваше утверждение о том, как устанавливается CPACK_PACKAGE_VERSION_XXX, неверно. Рассматриваемые переменные CPack устанавливаются командой project, если команда project определяет управление версиями. Поэтому, когда вы создаете ветку 1.2.9, вы должны установить 1.2.9 в качестве номера версии в команде проекта.

Из справки CPack

CPACK_PACKAGE_VERSION_MAJOR

Основная версия пакета. Эта переменная всегда будет установлена, но ее значение по умолчанию зависит от того, были ли сведения о версии переданы команде project () в файле CMakeLists.txt верхнего уровня. Если были указаны сведения о версии, значением по умолчанию будет CMAKE_PROJECT_VERSION_MAJOR. Если сведения о версии не указаны, будет использоваться версия по умолчанию 0.1.1, в результате чего CPACK_PACKAGE_VERSION_MAJOR будет иметь значение по умолчанию 0.

Команда проекта

> project(<PROJECT-NAME>
>         [VERSION <major>[.<minor>[.<patch>[.<tweak>]]]]
>         [DESCRIPTION <project-description-string>]
>         [HOMEPAGE_URL <url-string>]
>         [LANGUAGES <language-name>...])

Если вы не хотите устанавливать ВЕРСИЮ с помощью команды проекта, существует несколько других способов установки соответствующих переменных.

Примеры находятся: https://cmake.org/cmake-tutorial/

Также посмотрите, как CMake обрабатывает версии:

https://gitlab.kitware.com/cmake/cmake/blob/master/Source/CMakeVersionSource.cmake

https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmVersionConfig.h.in

Другой пример получения метаданных git для установки информации, связанной с версией: https://github.com/pmirshad/cmake-with-git-metadata/blob/master/CMakeLists.txt

person fdk1342    schedule 30.11.2018
comment
Спасибо. Я могу поиграть с использованием команды проекта, чтобы установить управление версиями, в соответствии с цитированными вами отрывками. Но я не нашел никакой документации, в которой говорилось бы, что CPACK_PACKAGE_VERSION_MAJOR не следует изменять после проекта. Погуглив, вижу несколько примеров этого. Это не значит, что это правильно ... Тем не менее, я не верю, что это имеет отношение к моей проблеме. Моя проблема в том, есть ли способ, чтобы когда кто-то загружал и строил проект github, чтобы полученная общая библиотека имела правильное управление версиями в своем имени? - person ChrisF; 30.11.2018
comment
Я добавил дополнительные примеры того, как установить версию в CMake. Казалось, просто установить поле ВЕРСИЯ в команде проекта. Вы также, похоже, обеспокоены тем, чтобы кто-то не мог изменить номер версии после того, как она была загружена. Вы не можете заставить их изменять переменные и версию. - person fdk1342; 30.11.2018
comment
Я не очень беспокоюсь о том, чтобы что-то менять после того, как они его загрузили. Я просто хотел, чтобы у библиотеки был правильный номер версии в имени, когда они собирают ее на своей собственной машине. Один из примеров, который вы предоставили, мне понравился. CMakeLists.txt может вызывать что-то вроде git describe для получения тегов, а затем анализировать теги, чтобы получить основной, второстепенный номер и номер патча для использования с cmake, чтобы общая библиотека имела правильное имя. Я думаю, что меня сбило с толку, так это то, что я думал о создании вне контекста git. Еще раз спасибо! - person ChrisF; 30.11.2018
comment
Конечно. Внимательно посмотрите, как CMake выполняет управление версиями, потому что он может определить, собираете ли вы из архива или из git. Если он обнаруживает, что исходная папка - это git, он примет версию (и если она грязная) во внимание или использует значения, указанные в файле, предоставленном в архиве. - person fdk1342; 01.12.2018