Russian Qt Forum

Здравствуйте. Есть небольшой С++ проект (использует qbs, если это поможет), который линкуется с внешней библиотекой, поставляемой  в бинарном виде (ее изменения не интересуют). Естественно, файл библиотеки разный для разных платформ. Назрел вопрос как лучше хранить эти файлы.

1. просто сложить всё в репозиторий: не нравится, т.к. это просто раздутие репозитория «ненужными» файлами (пользователю винды не нужны файлы Макос и т.п.)
2. залить библиотеки куда-нибудь и скачивать нужную версию после клонирования репозитория/перед сборкой: придется писать скрипты скачивания для curl/wget/и т.д., насколько я понимаю.
3. git submodule? но это ничем не отличается от п. 1, насколько я понимаю, просто лежать будут в другой ветке/репозитории.
4. может поможет замена qbs на cmake, если в последнем есть встроенные средства скачивания?
5. ваш вариант :)

Я лично противник того, чтобы система _сборки_ что-либо скачивала. Система _сборки_ должна собирать=) Хотя в Qbs есть такой тикет (https://bugreports.qt.io/browse/QBS-62)
Желание запихнуть всё в одно место понятно, но порочно.
К примеру, деб-пакеты собираются при помощи debuild, который читает зависимости из файлика debian/control. По очевидным причинам, эти зависимости не подойдут для венды/макоси/рпм дистрибутива.

На одной из работ был написан питоновский скрипт, который читает yaml* файлик зависимостей и качает через питоновский curl пакеты и распаковывает их в папочку. Юзался он соответственно на маке/венде, на линуксе юзался нативный споосб через deb-пакеты.
Плюс такого подхода в том, что он работал с любой системой сборки (основных было две - cmake и qbs).

* файлик для примера:

пункты 1 и 3.

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

файл зависимостей и скрипт на питоне — это слишком много на данный момент, к тому же в винде нет питона по умолчанию :)

с submodule я сначала не подумал, что можно сделать по модулю на каждую платформу, и уже в qbs прописать какой модуль стягивать (вроде ж можно сказать гиту, чтоб по умолчанию не качал все доступные?). спасибо!

еще как вариант рассматривал что-то типа скрипта «если нет файла, скачать», который под виндой будет вызываться через PowerShell, а в остальных случаях через sh/curl.

Судя по проектам на Гитхабе, народ делает каталог с исходниками программы, каталог distrib\ (и т.п.), а в нём подкаталоги по имени целевой платформы, в этих каталогах конфиги систем сборки свойственной для целевой платформы, ну и, видимо, эти системы сборки умеют докачать файлы библиотек и т.п.

Выглядит так, будто бы тебе нужен менеджер пакетов. Попробуй Conan (https://conan.io/index.html (https://conan.io/index.html)).

Но раз бинарь меняться не будет, то лично я бы не парился и хранил всё просто в какой-нибудь папке "3rd-party", например (первый пункт).

Это не будет лишним в любом случае. )

+1

нет, менеджер пакетов в данном случае не нужен :)

всем спасибо за ответы. воспользуюсь п. 1 как самым простым.

У себя используем 1 и 3. вот пример подобного сабмодуля https://bitbucket.org/planarllc/planar.tp.easy_profiler/wiki/Home

сабмодуль содержит в себе бинарники для всех необходимых ос и компиляторов. бинарники складываются в LFS.

в зависимом это этого сабмодуля проекте делаем include(<путь_к_директории_с_easy_profiler>/easy_profiler.pri). внутри pri-файла идёт разруливание - какие бинарники использовать в текущем окружении.

таким образом. клонирование происходит на этапе клонирования проекта, а не на этапе сборки. база git сама не пухнет, так как бинарные файлы в LFS. и да у нас qmake, а не qbs