Bazel: разделить макрос между несколькими файлами http_archive BUILD - PullRequest
1 голос
/ 23 апреля 2020

Мой проект зависит от некоторых внешних библиотек, которые я должен сам базировать. Таким образом, мои WORKSPACE:

http_archive(
    name = "external_lib_component1",
    build_file = "//third_party:external_lib_component1.BUILD",
    sha256 = "xxx",
    urls = ["https://example.org/external_lib_component1.tar.gz"],
)

http_archive(
    name = "external_lib_component2",
    build_file = "//third_party:external_lib_component2.BUILD",
    sha256 = "yyy",
    urls = ["https://example.org/external_lib_component2.tar.gz"],
)

...

Две записи выше аналогичны, и external_lib_component{1, 2}.BUILD разделяют много кода. Каков наилучший способ обмена кодом (макросами) между ними?

Простое помещение файла shared_macros.bzl в third_party/ не будет работать, поскольку оно не будет скопировано в расположение архива при сборке (только build_file копируется).

1 Ответ

2 голосов
/ 25 апреля 2020

Если вы поместите файл bzl, например, в вашем ./third_party/shared_macros.bzl, в свое дерево, как вы упомянули.

Затем в //third_party:external_lib_component1.BUILD и //third_party:external_lib_component2.BUILD вы предоставите свои внешние зависимости, Вы можете загрузить символы из этого общего файла, используя:

load("@//third_party:shared_macros.bzl", ...)

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


В качестве альтернативы вы также можете ссылаться на "родительский" проект по его имени. Ваш WORKSPACE файл, который у вас был:

workspace(name = "parent")

Вы можете сказать:

load("@parent//third_party:shared_macros.bzl", ...)

Примечание: в версиях до 2.0.0 вы можете добавить --incompatible_remap_main_repo, если вы смешали оба вышеуказанных подхода в своем проекте.

...