Bazel: ссылки на двоичные файлы из пакетов в пользовательском определении цепочки инструментов

Question

Фон

Я пытаюсь создать пользовательское определение цепочки инструментов, которое ссылается на двоичные файлы инструментов из загружаемого пакета.

Кажется, что еслиtool_path.pathявляется относительным Bazel считает его относительным относительно того, где определен набор инструментов. Бывший:${execroot}/toolchain.

http_archiveсодержимое пакета, с другой стороны, находится в${execroot}/external/gcc12

Путь к инструменту должен быть каноническим, поэтому вы не можете указать что-то вроде../external/gcc12/bin/gcc

Я просмотрел другие определения пользовательской цепочки инструментов, такие как:

• https://github.com/agoessling/bazel_bootlin
• https://github.com/grailbio/bazel-toolchain

Все они используют сценарии оболочки-оболочки, которые живут в соответствии с определением цепочки инструментов (поэтому на них можно ссылаться по относительному пути) и вызывают настоящие двоичные файлы черезexternal/gcc...который относится к execroot.

Хотя этот подход работает, он может вызвать проблемы сrules_foreign_cc(См. ) и в любом случае кажется хакерским.

https://github.com/bazelbuild/bazel/pull/10967 «Добавить необязательный tool_path_origin к инструментам в C++ crosstool» был объединен в мае 2020 года, что, по-видимому, позволяет оценивать относительные пути инструментов относительно корня рабочей области. Однако я не совсем понимаю, как вызвать такое поведение.

https://github.com/bazelbuild/bazel/issues/8438https://github.com/bazelbuild/bazel/issues/8438 ссылается на https://github.com/bazelbuild/bazel/pull/5809 как релевантное, но в конце концов оно было отклонено.

Другое соответствующее обсуждение можно найти по адресу https://github.com/bazelbuild/bazel/issues/7746 .

Вопрос

Можно ли ссылаться на двоичные файлы цепочки инструментов Bazel из внешнего пакета, не прибегая к сценариям оболочки-оболочке?

Answer 1

Насколько я понимаю, это в основном реализовано сейчас. Хотя интерфейс довольно болезненный в использовании и требует много шаблонов. Как вы упомянули, это было представлено в https://github.com/bazelbuild/bazel/pull/10967 . Но практически нет документации о том, как использовать эту новую функцию.

После следования хлебным крошкам создаю свои собственные наборы инструментов. Я обнаружил, что есть два совершенно разных интерфейса для определения ваших инструментов. Первое, о чем вы упомянули, это использование атрибута tool_paths. На данный момент нет способа обойти сценарий оболочки. Этот подход довольно хорошо задокументирован, и я предполагаю, что это то, что вы сейчас делаете.

Второй — использовать метод action_config в сочетании с отдельным конструктором .

Из инструментастроки документации ;

          Describes a tool associated with a crosstool action config.

    Args:
        path: Location of the tool; Can be absolute path (in case of non hermetic
            toolchain), or path relative to the cc_toolchain's package. If this
            parameter is set, tool must not be set.
        tool: The built-artifact that should be used as this tool. If this is
            set, path must not be set.

Итак, это выглядит примерно так;

      action_config (
    config_name = ACTION_NAMES.cpp_link_executable,
    action_name = ACTION_NAMES.cpp_link_executable,
    tools = [
        # NEW label type tool field introduced in #10967
        tool(tool = ctx.executable.my_ld),
    ],
)

Чтобы это работало в вашей цепочке инструментов, вам нужно пройти и создать action_config для каждого из ACTION_NAMES. Затем вы передаете свой список action_configs в ваш toolchain_config.

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