Как передать массив из Bazel cli в правила? - PullRequest
0 голосов
/ 24 февраля 2020

Допустим, у меня есть такое правило:

foo(
    name = "helloworld",
    myarray = [
        ":bar",
        "//path/to:qux",
    ],
)

В этом случае myarray - это состояние c. Тем не менее, я хочу, чтобы он был задан cli, как

bazel run //:helloworld --myarray=":bar,//path/to:qux,:baz,:another"

Как это возможно?

Спасибо

Ответы [ 2 ]

0 голосов
/ 25 февраля 2020

Вопрос в том, что вы действительно после. Передача переменной, массива в bazel build/run на самом деле невозможна, ну не как таковая и не (в основном) без (весьма вероятных нежелательных) побочных эффектов. Разве вы, возможно, на самом деле не просто пытаетесь передать аргументы непосредственно тому, что управляет run? Т.е. передать его самому исполняемому файлу, а не bazel?

Есть несколько способов, которыми вы могли бы проникнуть внутрь (вам также в большинстве случаев нужно было бы придумать синтаксис для передачи данных в CLI и распаковать массив как правило), но многие приходят с относительно существенной ценой.

  • Вы можете определить свой массив в файле bzl и загрузить его из того места, где его использует правило. Затем вы можете сбросить содержимое bzl, переписав вашу конфигурацию сборки / запуска (что также делает ее очевидной, отслеживаемой) и загрузить биты из правила (влияющие только на загрузку правила и использование переменной). Например, BUILD file:

    load(":myarray.bzl", "myarray")
    foo(
        name = "helloworld",
        myarray = myarray,
        ],
    )
    

    И затем вы можете назвать свою сборку:

    $ echo 'myarray=[":bar", "//path/to:qux", ":baz", ":another"]' > myarray.bzl
    $ bazel run //:helloworld 
    

    которую вы, конечно, можете поместить в один скрипт-обертку. Если это действительно массив bazel, возможно, это самый чистый способ сделать это.

  • --workspace_status_command: вы можете собирать информацию о вашей среде добавьте один или оба полученных файла (в зависимости от того, предназначены ли входные данные для аннулирования результатов правила или нет, вы можете использовать изменяемые или стабильные файлы состояния) в качестве зависимости вашего правила и обработать входящий файл в том, что происходит выполняется по правилу (после чего можно задаться вопросом, почему бы не передать его в качестве аргументов командной строки напрямую). Если используется стабильный файл состояния, любое другое правило, в зависимости от него, становится недействительным при любом изменении.

  • Вы можете сделать то же самое, используя --action_env. Из исполняемого файла / инструмента / скрипта, лежащего в основе правила, вы можете напрямую получить доступ к определенной переменной среды. Однако это также означает, что это влияет на среду каждого правила (а не только на то, на которое вы ориентируетесь); и еще раз, зачем ему анализировать информацию из окружения и не принимать аргументы в командной строке.
  • Существует также --define, но вы бы не получили прямого доступа к его значению, так как Насколько вы могли select() выбор из возможных вариантов.
0 голосов
/ 25 февраля 2020

Чтобы получить именно то, что вы запрашиваете, Bazel потребуется поддержка LABEL_LIST в определяемых Starlark флагах командной строки, которые описаны здесь:

https://docs.bazel.build/versions/2.1.0/skylark/lib/config.html

и здесь: https://docs.bazel.build/versions/2.1.0/skylark/config.html

К сожалению, на данный момент это не реализовано.

Если вам не нужен список меток (т.е. (для создания зависимостей между целями), тогда, возможно, STRING_LIST будет работать для вас.

Если вам нужен список меток, и известны различные возможные значения, тогда вы можете использовать --define, config_setting() и select():

https://docs.bazel.build/versions/2.1.0/configurable-attributes.html

...