LINUX.ORG.RU

История изменений

Исправление eao197, (текущая версия) :

Нам для упрощения разработки кросс-платформенного софта на C++ пришлось сделать собственный велосипед на Ruby, который успешно используется уже около полугода в повседневной работе. Принцип такой: указывается откуда и что забирать (это может быть URL архива или URL репозитория (git, hg, svn), а затем что и куда из этого копировать. Грубо говоря, указывается URL архива библиотеки, эта библиотека скачивается, распаковывается в отдельном каталоге, а оттуда уже нужные тебе куски копируются в нужные тебе подкаталоги. Чуть подробнее на эту тему: http://http//eao197.blogspot.com.by/2016/04/prog-mxxru-1610-mxxruexternals.html и http://eao197.blogspot.com.by/2016/04/prog-mxxruexternals.html

У получившегося у нас инструмента есть две важных особенности:

  • если библиотека задействуется в нескольких проектах, то в каждый проект она будет скопирована отдельно;
  • за версиями библиотеки нужно следить самостоятельно (т.е. если у библиотеки появилась новая версия, то эту версию прописывать в зависимостях нужно явно). Разве что если библиотека качается напрямую из репозитория без привязки к тегу/коммиту, то при перезагрузки зависимостей будет взята самая свежая версия из репозитрия.

Но для нас эти возможности были ключевыми, поэтому мы так и сделали. Нужна была возможность в точности взять версию проекта со всеми его подпроектами.

Полагаю, что на ваш сценарий, когда вы вносите правки в libA и libB прямо в рабочей копии appA, это не ляжет. Но это не самый лучший сценарий, имхо.

Большие зависимости вроде Boost или ACE подтягивать пока не приходилось, но подтянуть SOCI, rapidjson, catch, fmtlib, spdlog, procxx и еще десятка полтора подобного размера библиотек в проект получается запросто.

При этом механизм получился не привязанный к build-системам. Т.е. качать зависимости можно с помощью MxxRu::externals, а собирать затем все — через CMake или через что-то еще. Ну а на Ruby делали потому, что так было проще и быстре.

Маленький пример: 

MxxRu::arch_externals :libmosquitto do |e|
  e.url 'https://github.com/eclipse/mosquitto/archive/v1.4.8.zip'

  e.map_dir 'lib' => 'dev/libmosquitto'
  e.map_file 'config.h' => 'dev/libmosquitto/*'
end

MxxRu::arch_externals :fmt do |e|
  e.url 'https://github.com/fmtlib/fmt/archive/3.0.0.zip'

  e.map_dir 'cppformat' => 'dev/fmt'
  e.map_dir 'fmt' => 'dev/fmt'
end

MxxRu::arch_externals :spdlog do |e|
  e.url 'https://github.com/gabime/spdlog/archive/v0.9.0.zip'

  e.map_dir 'include' => 'dev/spdlog'
end

MxxRu::arch_externals :catch do |e|
  e.url 'https://github.com/philsquared/Catch/archive/v1.5.6.tar.gz'

  e.map_file 'single_include/catch.hpp' => 'dev/catch/*'
end

MxxRu::git_externals :rapidjson do |e|
  e.url 'https://github.com/miloyip/rapidjson.git'
  e.commit '2a3fbdaf5c6991124dacbd9fcdf709f9b044ffe5'
  e.map_dir 'include/rapidjson' => 'dev/rapidjson/include'
end

Исходная версия eao197, :

Нам для упрощения разработки кросс-платформенного софта на C++ пришлось сделать собственный велосипед на Ruby, который успешно используется уже около полугода в повседневной работе. Принцип такой: указывается откуда и что забирать (это может быть URL архива или URL репозитория (git, hg, svn), а затем что и куда из этого копировать. Грубо говоря, указывается URL архива библиотеки, эта библиотека скачивается, распаковывается в отдельном каталоге, а оттуда уже нужные тебе куски копируются в нужные тебе подкаталоги. Чуть подробнее на эту тему здесь и здесь.

У получившегося у нас инструмента есть две важных особенности:

  • если библиотека задействуется в нескольких проектах, то в каждый проект она будет скопирована отдельно;
  • за версиями библиотеки нужно следить самостоятельно (т.е. если у библиотеки появилась новая версия, то эту версию прописывать в зависимостях нужно явно). Разве что если библиотека качается напрямую из репозитория без привязки к тегу/коммиту, то при перезагрузки зависимостей будет взята самая свежая версия из репозитрия.

Но для нас эти возможности были ключевыми, поэтому мы так и сделали. Нужна была возможность в точности взять версию проекта со всеми его подпроектами.

Полагаю, что на ваш сценарий, когда вы вносите правки в libA и libB прямо в рабочей копии appA, это не ляжет. Но это не самый лучший сценарий, имхо.

Большие зависимости вроде Boost или ACE подтягивать пока не приходилось, но подтянуть SOCI, rapidjson, catch, fmtlib, spdlog, procxx и еще десятка полтора подобного размера библиотек в проект получается запросто.

При этом механизм получился не привязанный к build-системам. Т.е. качать зависимости можно с помощью MxxRu::externals, а собирать затем все — через CMake или через что-то еще. Ну а на Ruby делали потому, что так было проще и быстре.

Маленький пример: 

MxxRu::arch_externals :libmosquitto do |e|
  e.url 'https://github.com/eclipse/mosquitto/archive/v1.4.8.zip'

  e.map_dir 'lib' => 'dev/libmosquitto'
  e.map_file 'config.h' => 'dev/libmosquitto/*'
end

MxxRu::arch_externals :fmt do |e|
  e.url 'https://github.com/fmtlib/fmt/archive/3.0.0.zip'

  e.map_dir 'cppformat' => 'dev/fmt'
  e.map_dir 'fmt' => 'dev/fmt'
end

MxxRu::arch_externals :spdlog do |e|
  e.url 'https://github.com/gabime/spdlog/archive/v0.9.0.zip'

  e.map_dir 'include' => 'dev/spdlog'
end

MxxRu::arch_externals :catch do |e|
  e.url 'https://github.com/philsquared/Catch/archive/v1.5.6.tar.gz'

  e.map_file 'single_include/catch.hpp' => 'dev/catch/*'
end

MxxRu::git_externals :rapidjson do |e|
  e.url 'https://github.com/miloyip/rapidjson.git'
  e.commit '2a3fbdaf5c6991124dacbd9fcdf709f9b044ffe5'
  e.map_dir 'include/rapidjson' => 'dev/rapidjson/include'
end