хранение бинарных зависимостей в кросс-платформенном проекте

[kambala]

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

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

[Авварон]

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

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

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

Код:

name: foo
version: 0.0.0
desc: >
  BarBaz
depends:
  zlib: {dist: win32}
  curl: {dist: win32}
  libyaml:
  zeromq3:
  cmake:

[kuzulis]

пункты 1 и 3.

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

[kambala]

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

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

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

[lit-uriy]

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

[ksk-]

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

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

[ksk-]

4. может поможет замена qbs на cmake

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

[_Bers]

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

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

+1

[kambala]

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

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

[zhbr]

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

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

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

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