Для монолитного c репо следует использовать один или несколько рабочих баз? - PullRequest
Новая
       13

Для монолитного c репо следует использовать один или несколько рабочих баз?

0 голосов
/ 28 января 2020

Мы помещаем все продукты и библиотеки в один монолитный c git репозиторий. Его компоновка выглядит следующим образом: 

- FooProduct
- BarProduct
- BazLibrary
- 3rd_party
 |- fftw
 |- msgpack
 |- zlib

В настоящее время мы используем CMake для управления сборкой. Так как CMake разделил этапы конфигурации, генерации и сборки, выполнение всех этих действий потребовало бы очень много времени. Чтобы избежать этого, мы даем верхний уровень CMakeLists.txt для каждой части, а также ссылаемся на проекты равноправных участников на вызовах верхнего уровня add_subirectory. Например: 

# FooProduct/CMakeLists.txt
project(FooProduct)
add_subdirectory(../BazLibrary sibling/BazLibrary)
add_subdirectory(../3rd_party/zlib sibling/3rd_party/zlib)
......

Теперь мы оцениваем Bazel , и у меня сразу же возник вопрос: должен ли я разместить только один сингл WORKSPACE в верхнем каталоге репо git? 

- WORKSPACE
- FooProduct
- BarProduct
- BazLibrary
- 3rd_party
 |- fftw
 |- msgpack
 |- zlib

Или поместить много файлов WORKSPACE в каждый продукт / библиотеку и ссылаться друг на друга, используя правило local_repository? 

- FooProduct
 |- WORKSPACE
- BarProduct
 |- WORKSPACE
- BazLibrary
 |- WORKSPACE
- 3rd_party
 |- fftw
   |- WORKSPACE
 |- msgpack
   |- WORKSPACE
 |- zlib
   |- WORKSPACE

1 Ответ

1 голос
/ 28 января 2020

В одном рабочем пространстве или в дереве исходных текстов / сборок по определению есть только одно (верхний уровень) WORKSPACE. Теоретически вы можете поместить WORKSPACE ветви вашего дерева, но один очевидный источник путаницы заключается в том, что вы не можете достичь целей проекта при запуске bazel из каталогов, где другая WORKSPACE находится на пути между cwd и проектом root. Хотя вы не получите ничего взамен.

Если вы хотите распределить свою конфигурацию по нескольким каталогам (или даже подмодулям), вы можете добавить файлы Starlark (.bzl) с макросами («функциями») определить соответствующие цели правил репозитория (внешние зависимости) в любом месте вашего дерева (например, //3rd_party/...), загрузить и выполнить соответствующие соответствующие определения в вашем (проекте) WORKSPACE файле.

Но это было бы больше организационные вопросы (например, разные люди / группы, поддерживающие разные зависимости или просто сохраняющие файлы небольшими), эффективно это работает (в конечном итоге оценивается) так же, как наличие одного большого файла WORKSPACE.

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

...