Bazel: Смешивание платформы удаленного выполнения Linux с локальной платформой ОС Ma c. - PullRequest
Новая
       90

Bazel: Смешивание платформы удаленного выполнения Linux с локальной платформой ОС Ma c.

1 голос
/ 03 мая 2020

Цель

Я использую Bazel для создания мультиплатформенного клиента C ++ (iOS, OSX, Android, Windows).

iOS и OSX создаются локально на моей маме c (по необходимости). Android и Windows встроены в контейнер Docker.

В конце сборки у меня есть правило Базеля, которое берет каждое правило cc_binary для каждой платформы и помещает их в .zip.

Я хотел бы использовать API удаленного выполнения Bazel для создания некоторых из моих двоичных файлов в контейнере и других локально, а затем ссылаться на общий кэш для их сопоставления - все с помощью одной команды bazel build.

Поддержка Bazel

Bazel утверждает, что эти типы сборок multiplatform - там, где платформы host (OSX x64), execution (Linux x64) и target ( многие) все разные - возможны.

См. https://docs.bazel.build/versions/master/platforms.html

Мой опыт

Однако я столкнулся с этой точной проблемой: https://github.com/bazelbuild/bazel/issues/5397 (где docker-sandbox - правильный прокси для remote сборок.)

Это, наряду с проблемой Github, приведенной ниже, заставляет меня усомниться в утверждении Базеля о multiplatform сборках.

https://github.com/bazelbuild/bazel/issues/5309

По сути, эти проблемы говорят о том, что локальные цели для одной платформы (например, OSX) нельзя построить рядом с удаленными целями на другой платформе (например, * 1067). *).

Вопрос

Мне было интересно:

(1) То, что я пытаюсь сделать в корне, противоречит замыслу Базеля? Если так, что означает, что Bazel означает multiplatform?

(2) Есть ли обходной путь, который я могу использовать, который поддерживает герметичность и остается в системе сборки Bazel? Можно было бы смонтировать том Docker и затем написать сценарий, который объединяет кэш Docker с моим локальным кешем, но кажется, что Bazel был создан для обработки моего варианта использования. Я что-то здесь упускаю?

Смежные вопросы: Поддерживает ли Bazel удаленное выполнение на разных платформах? (Не дает удовлетворительного ответа.)

1 Ответ

2 голосов
/ 03 мая 2020

(1) То, что я пытаюсь сделать принципиально, расходится с дизайном Базеля?

В теории нет, на практике да. Bazel предоставляет функциональность, которая позволяет пользователям поддерживать ваш вариант использования, но он не реализован по умолчанию.

В частности, как описано в связанных проблемах Bazel: Bazel rules в настоящее время делает предположения о отношения между хост-платформой и целевой платформой, которые не поддерживаются в вашем случае, например, он автоматически обнаружит файлы JDK на вашем хосте (macOS) и затем по умолчанию будет использовать эти файлы JDK во всех действиях Java - независимо от целевой платформы .

Если так, что означает, что Bazel является мультиплатформенным?

На практике это означает, что вы можете запустить bazel build ... на нескольких платформах и ожидать, что Bazel будет преобразовать ваши входы в выходы, совместимые с текущей платформой.

(2) Есть ли способ, который я могу использовать, который поддерживает герметичность и остается в системе сборки Bazel?

Да, вы можете запустить bazel build ... из контейнера Windows VM или Docker. Это был обходной путь, который команда Bazel рекомендовала, когда я задал этот вопрос.

Соответствующие расширенные функции Bazel:

  • Если вы хотите создать несколько целевых платформ с одним вызовом Bazel, сделайте взгляните на пользовательские переходы Bazel (это позволит вам создать одно и то же правило для нескольких платформ, например, iOS и macOS одновременно, но потребует написания собственных правил).
  • Если вы не хотите запускать bazel build из контейнеров / виртуальных машин, вы можете написать свой собственный набор инструментов C ++ . По своей сути Bazel предоставляет каждому действию изолированную программную среду со всеми зависимыми файлами и гарантирует, что оно выполнит указанную команду c. В пользовательской цепочке инструментов C ++ вы могли бы сказать Bazel, чтобы он вызывал сценарий вместо clang, который принимает команду + файлы и выполняет их из виртуальной машины или контейнера. Это вероятно много работы, но определенно возможно.
...