Как может работать внешняя зависимость и мой проект одновременно в bazel?

Question

Как может работать внешняя зависимость и мой проект одновременно в bazel?

2

Мой вопрос касается субпроектов и работы над ними вместе со своими зависимостями в базеле.

У меня есть проект c++, над которым я работаю. Назовите это проектом A.

Проект A зависит от 2 других, над которыми я работаю, B и C.

Проект B также зависит от проекта C.

поэтому он выглядит так.

A -> (B, C)
B -> (C)
C -> no external dependencies

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

Я попробовал несколько способов настроить это:

Внешние зависимости от git в моем файле WORKSPACE. Здесь проблема в том, что когда я хочу внести в них изменения, как если бы они были одним большим проектом, они не синхронизируются. Рабочий процесс также неудобен, чтобы постоянно переключаться с каталогов, нажимать мой репозиторий, возвращаться к другому, и потенциально пытаться (если бэзел решает это сделать, все равно не знаю, как его заставить).
Git подмодулей и внешних зависимостей в репозитории. Здесь проблема в CLion или что-то, что я использую для перехода к ссылке, фактически получает ее ссылку из специально созданного кэша базы, где-то, а не фактическое репо, которое я хотел бы зафиксировать.
Git, когда подмодули - это просто пакеты, от которых я зависим. Это было бы моим любимым решением, но если я это сделаю, файлы BUILD в каждом из подмодулей (все хранятся в third_party или какой-либо другой каталог) являются недопустимыми, так как сами они зависят от внешних зависимостей. Например, проект B включает C как внешнюю зависимость NOT в рабочей области, в которой я работаю, но в этом рабочем пространстве C представляет собой пакет. Единственный способ, с помощью которого я могу справиться, - это переписать все файлы сборки для каждого пакета, в который включена библиотека Bazel. Это не кажется продуктивным.

Я знаю, что в google мы используем другую версию этого, и мы сохраняем все это во внутренней рабочей области, но для этого должно быть решение для bazel.

Brandon Ross Pollack 25 июль 2018, в 08:19

Источник

0

пожалуйста, посмотрите на local_repository docs.bazel.build/versions/master/be/…
Bhavik 26 июль 2018, в 05:50
0

Но работает ли это с clion, чтобы перейти к правильному определению? Это также требует, чтобы любой, кто клонирует мой репозиторий, имел эти
Brandon Ross Pollack 26 июль 2018, в 20:57

Теги:

c++

git

bazel

clion

git-submodules

2 ответа

0

Таким образом, общее решение, которое я нашел для работы, - создать monorepo и использовать такой инструмент, как copybara, для создания автономных выпусков каждого из пакетов.

Brandon Ross Pollack 25 июль 2018, в 22:45

0

Кажется, у меня похожая проблема, и я хотел бы обратиться к вам за советом. Моя проблема может быть проще, чем ваша, так как я просто хочу построить игрушечный проект C ++, который использует abseil и gtest. Я не собираюсь менять abseil или gtest. Репозиторий Bazel {local, git, http} _ будет работать, но Clion, похоже, не понимает их, поэтому не может дать синтаксическую помощь (с чем, я полагаю, вы также столкнулись?). Поэтому лучше всего копировать зависимости в мое собственное хранилище (например, copybara)? Спасибо, Брэндон!
bill 14 апр. 2019, в 19:46
0

Я думаю, что лучше всего использовать файлы BUILD, включенные в эти проекты с помощью правил файлов рабочих пространств. Iirc clion обнаружит его с помощью плагина Blaze после сборки
Brandon Ross Pollack 14 апр. 2019, в 20:31
0

Если это не сработает, тогда monorepo (возможно, подмодули git, возможно, копии head и copybara, до вас)
Brandon Ross Pollack 14 апр. 2019, в 20:33

Показать ещё 1 комментарий

Ещё вопросы

пожалуйста, посмотрите на local_repository docs.bazel.build/versions/master/be/…
Но работает ли это с clion, чтобы перейти к правильному определению? Это также требует, чтобы любой, кто клонирует мой репозиторий, имел эти
Кажется, у меня похожая проблема, и я хотел бы обратиться к вам за советом. Моя проблема может быть проще, чем ваша, так как я просто хочу построить игрушечный проект C ++, который использует abseil и gtest. Я не собираюсь менять abseil или gtest. Репозиторий Bazel {local, git, http} _ будет работать, но Clion, похоже, не понимает их, поэтому не может дать синтаксическую помощь (с чем, я полагаю, вы также столкнулись?). Поэтому лучше всего копировать зависимости в мое собственное хранилище (например, copybara)? Спасибо, Брэндон!
Я думаю, что лучше всего использовать файлы BUILD, включенные в эти проекты с помощью правил файлов рабочих пространств. Iirc clion обнаружит его с помощью плагина Blaze после сборки
Если это не сработает, тогда monorepo (возможно, подмодули git, возможно, копии head и copybara, до вас)

Rodrigo Queiro · Accepted Answer · 2018-07-25T12-00-00.000Z

Для аналогичного --override_repository использования (тестирование изменений сторонних зависимостей перед отправкой запроса на --override_repository я использую рабочий процесс на основе --override_repository. Это говорит Bazel не вытаскивать данный внешний репозиторий из Github, а вместо этого использовать копию на вашем локальном диск.

Например, в вашем случае у меня может быть этот макет:

> ls ~/git
project_a
project_b
project_c

Я могу внести изменения внутри ~/git/project_b а затем построить проект A следующим образом:

cd ~/git/project_b
# edit files
cd ~/git/project_a
bazel build //... --override_repository com_github_username_project_b=$HOME/git/project_b

Вы также можете добавить строку build --override_repository name=/path/to/repo в .bazelrc но я предпочитаю не делать этого, чтобы я не отправлял код, зависящий от неопределенного изменения зависимостей.

это разумное решение, у меня есть вопрос, открытый на CLion. Они думают, что это может быть ошибкой, и вместо этого следует ссылаться на указанный репозиторий, если это не сработает, тогда это отличный вариант (особенно, когда библиотека более стабильна)
К сожалению, это не заставляет CLion переходить по ссылкам на правильный файл :(