Reglas generales

Reglas

• alias
• config_setting
• grupo de archivos
• consulta de generación de demanda
• genrule
• test_suite

alias

alias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)

La regla alias crea otro nombre con el que se puede hacer referencia a una regla.

La asignación de alias solo funciona para “normal” objetivos. En particular, package_group y test_suite no pueden tener un alias.

La regla de alias tiene su propia declaración de visibilidad. En todos los demás aspectos, se comporta como la regla a la que hace referencia (p.ej., testonly en el alias se ignora; el testonly-ness de la regla a la que se hace referencia) con algunas excepciones menores:

• Las pruebas no se ejecutan si su alias se menciona en la línea de comandos. Cómo definir un alias que ejecute la prueba a la que se hace referencia, usa un test_suite. regla con un único destino en su tests .
• Cuando se definen grupos de entornos, los alias de las reglas environment no son no es compatible. No se admiten en la línea de comandos de --target_environment. la opción de protección de datos.

Ejemplos

filegroup(
    name = "data",
    srcs = ["data.txt"],
)

alias(
    name = "other",
    actual = ":data",
)

Argumentos

config_setting

config_setting(name, constraint_values, define_values, deprecation, distribs, features, flag_values, licenses, tags, testonly, values, visibility)

Coincide con un estado de configuración esperado (expresado como marcas de compilación o restricciones de plataforma) para con el objetivo de activar atributos configurables. Consulta seleccionar para cómo consumir esta regla y Atributos configurables para obtener una descripción general de las funciones generales.

Ejemplos

La siguiente coincide con cualquier compilación que establezca --compilation_mode=opt o -c opt (ya sea de forma explícita en la línea de comandos o implícitamente desde archivos .bazelrc):

  config_setting(
      name = "simple",
      values = {"compilation_mode": "opt"}
  )
  

El siguiente coincide con cualquier compilación que se oriente a ARM y aplique la definición personalizada FOO=bar (por ejemplo, bazel build --cpu=arm --define FOO=bar ...):

  config_setting(
      name = "two_conditions",
      values = {
          "cpu": "arm",
          "define": "FOO=bar"
      }
  )
  

La siguiente coincide con cualquier compilación que establezca marca definida por el usuario --//custom_flags:foo=1 (ya sea de forma explícita en la línea de comandos o implícitamente desde .bazelrc):

  config_setting(
      name = "my_custom_flag_is_set",
      flag_values = { "//custom_flags:foo": "1" },
  )
  

Lo siguiente coincide con cualquier compilación orientada a una plataforma con arquitectura x86_64 y glibc versión 2.25, suponiendo la existencia de un constraint_value con etiqueta //example:glibc_2_25 Ten en cuenta que una plataforma coincide si define restricciones más allá de estos dos.

  config_setting(
      name = "64bit_glibc_2_25",
      constraint_values = [
          "@platforms//cpu:x86_64",
          "//example:glibc_2_25",
      ]
  )
  

Notas

• Consulta seleccionar para saber qué sucede cuando varias config_setting coincide con el estado de configuración actual.
• Para marcas que admiten formas abreviadas (p. ej., --compilation_mode frente a -c), las definiciones de values deben usar el formato completo. Estos se configuran automáticamente hacer coincidir las invocaciones con cualquiera de las dos formas.
• Si una marca toma múltiples valores (como --copt=-Da --copt=-Db o una etiqueta marca de Starlark), values = { "flag": "a" } coincide si "a" es presente en cualquier parte de la lista.

  values = { "myflag": "a,b" } funciona de la misma manera: coincide con --myflag=a --myflag=b, --myflag=a --myflag=b --myflag=c --myflag=a,b y --myflag=c,b,a. La semántica exacta varía entre marcas. Por ejemplo, --copt no admite varios valores en la misma instancia: --copt=a,b produce ["a,b"], mientras que --copt=a --copt=b produce ["a", "b"] (por lo tanto, values = { "copt": "a,b" } coincide con el primero, pero no con el último). Pero --ios_multi_cpus (para las reglas de Apple) hace: -ios_multi_cpus=a,b y ios_multi_cpus=a --ios_multi_cpus=b producen ["a", "b"]. Verifica las definiciones de las marcas y prueba condiciones con atención para verificar las expectativas exactas.

• Si necesitas definir condiciones que no estén modeladas con marcas de compilación integradas, usa Marcas definidas por Starlark. También puedes usar --define, pero este ofrece un valor más débil. asistencia y no se recomienda. Consulta aquí para obtener más información.
• Evita repetir definiciones idénticas de config_setting en diferentes paquetes. En su lugar, haz referencia a un config_setting común que se definió en un paquete canónico.
• values: define_values y constraint_values puede usarse en cualquier combinación en el mismo config_setting, pero al menos uno debe se puede establecer para cualquier config_setting.

Argumentos

            config_setting(
                name = "a_and_b",
                values = {
                    "define": "a=1",
                    "define": "b=2",
                })
          

            config_setting(
                name = "a_and_b",
                define_values = {
                    "a": "1",
                    "b": "2",
                })
          

grupo de archivos

filegroup(name, srcs, data, compatible_with, deprecation, distribs, features, licenses, output_group, restricted_to, tags, target_compatible_with, testonly, visibility)

Usa filegroup para asignar un nombre conveniente a una colección de destinos. Luego, otras reglas pueden hacer referencia a ellas.

Se recomienda usar filegroup en lugar de hacer referencia a directorios directamente. Esta última opción no tiene buen sonido, ya que el sistema de compilación no tiene conocimientos completos de todos los archivos. debajo del directorio, por lo que es posible que no se vuelva a compilar cuando cambien estos archivos. Cuando se combina con glob, filegroup puede garantizar que todos los archivos se que el sistema de compilación conoce explícitamente.

Ejemplos

Para crear un filegroup que conste de dos archivos de origen, haz lo siguiente:

filegroup(
    name = "mygroup",
    srcs = [
        "a_file.txt",
        "some/subdirectory/another_file.txt",
    ],
)

O bien, usa un glob para agrupar un directorio testdata:

filegroup(
    name = "exported_testdata",
    srcs = glob([
        "testdata/*.dat",
        "testdata/logs/**/*.log",
    ]),
)

Para usar estas definiciones, haz referencia a filegroup con una etiqueta de cualquier regla:

cc_library(
    name = "my_library",
    srcs = ["foo.cc"],
    data = [
        "//my_package:exported_testdata",
        "//my_package:mygroup",
    ],
)

Argumentos

consulta generativa

genquery(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, expression, features, licenses, opts, restricted_to, scope, strict, tags, target_compatible_with, testonly, visibility)

genquery() ejecuta una consulta especificada en el archivo Usa el lenguaje de consulta Blaze y vuelca el resultado. en un archivo.

Para mantener la coherencia de la compilación, solo se permite que la consulta visite el cierre transitivo de los objetivos especificados en el scope . Las consultas que infrinjan esta regla fallarán durante la ejecución si strict no se especifica o es verdadero (si strict es falso, los objetivos fuera del alcance se omitirán con una advertencia). El la forma más sencilla de asegurarse de que esto no suceda es mencionar las mismas etiquetas en el alcance, como en la expresión de la consulta.

La única diferencia entre las consultas permitidas aquí y en el comando es que las consultas que contienen especificaciones de destino comodín (p.ej., //pkg:* o //pkg:all) no se permiten aquí. Esto se debe a dos aspectos: en primer lugar, porque genquery tiene para especificar un alcance para evitar objetivos fuera del cierre transitivo del para influir en su resultado; y, en segundo lugar, porque archivos BUILD No admiten dependencias de comodín (p. ej., deps=["//a/..."]). no se permite).

El resultado de la consulta general se ordena con --order_output=full en para aplicar un resultado determinista.

El nombre del archivo de salida es el nombre de la regla.

Ejemplos

En este ejemplo, se escribe la lista de etiquetas en el cierre transitivo de la un destino especificado a un archivo.

genquery(
    name = "kiwi-deps",
    expression = "deps(//kiwi:kiwi_lib)",
    scope = ["//kiwi:kiwi_lib"],
)

Argumentos

genrule

genrule(name, srcs, outs, cmd, cmd_bash, cmd_bat, cmd_ps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exec_tools, executable, features, licenses, local, message, output_licenses, output_to_bindir, restricted_to, tags, target_compatible_with, testonly, toolchains, tools, visibility)

Una genrule genera uno o más archivos con un comando Bash definido por el usuario.

Las genrules son reglas de compilación genéricas que puedes usar si no hay una regla específica para la tarea. Por ejemplo, puedes ejecutar una frase en Bash. Sin embargo, si necesitas compilar archivos C++, a las reglas existentes de cc_* porque ya se hizo todo el trabajo pesado por ti.

No uses una genrule para ejecutar pruebas. Existen dispensaciones especiales para pruebas resultados, incluidas las políticas de almacenamiento en caché y las variables de entorno. Por lo general, las pruebas deben ejecutarse después de que se completa la compilación y en la arquitectura de destino, mientras que las genrules se ejecutan durante en la compilación y en la arquitectura del host (es posible que ambos sean diferentes). Si necesitas un perfil regla de prueba, usa sh_test.

Consideraciones sobre la compilación cruzada

Consulta el manual del usuario para obtener más información sobre compilación cruzada.

Si bien las genrules se ejecutan durante una compilación, sus resultados suelen usarse después de la compilación, para la implementación o y pruebas. Considera el ejemplo de compilación de código C para un microcontrolador: el compilador acepta C y genera código que se ejecuta en un microcontrolador. Obviamente, el código generado no se puede ejecutar en la CPU que se usó para compilarla, pero el compilador C (si se compiló desde el código fuente) debe hacerlo.

El sistema de compilación usa la configuración del host para describir las máquinas en las que se ejecuta la compilación. y la configuración de destino para describir las máquinas en las que se encuentra el resultado de la compilación que se suponía que debía ejecutarse. Proporciona opciones para configurar cada uno de ellos y segrega en directorios separados para evitar conflictos.

En el caso de las genrules, el sistema de compilación garantiza que las dependencias se compilen de forma correcta: Se compilan srcs (si es necesario) para la configuración de destino. Los tools se compilan para la configuración del host, y la salida se considera como para la configuración de destino. También proporciona "Marca" variables que los comandos de genrule pueden pasar a las herramientas correspondientes.

Genrule no define ningún atributo deps de forma intencional; se usan otras reglas integradas metainformación dependiente del idioma que se pasa entre las reglas para determinar automáticamente cómo manejan reglas dependientes, pero este nivel de automatización no es posible para las genrules. Funcionan las reglas generales solo a nivel de archivo y runfiles.

Casos especiales

Compilación host-host: En algunos casos, el sistema de compilación debe ejecutar genrules para que El resultado final también se puede ejecutar durante la compilación. Si, por ejemplo, una genrule compila algún compilador personalizado que luego usa otra genrule, la primera debe producir su salida para el de host, ya que allí es donde se ejecutará el compilador en la otra genrule. En este caso, el sistema de compilación hace lo correcto automáticamente: compila el srcs y outs de la primera genrule para la configuración del host en lugar del destino configuración. Consulta el manual del usuario para obtener más información información.

JDK y Herramientas de C++: Para usar una herramienta del JDK o el conjunto del compilador C++, el sistema de compilación proporciona un conjunto de variables para usar. Ver "Marca" variable para más detalles.

Entorno de Genrule

Una shell Bash configurada para fallar cuando se ejecuta un comando o si falla una canalización, a través de set -e -o pipefail.

La herramienta de compilación ejecuta el comando Bash en un entorno de procesos depurado que define solo variables principales, como PATH, PWD, TMPDIR y algunos más. Para garantizar que las compilaciones sean reproducibles, la mayoría de las variables definidas en la shell del usuario no se pasan al comando de genrule. Sin embargo, Bazel (pero no Blaze) pasa el valor de la variable de entorno PATH del usuario. Cualquier cambio en el valor de PATH hará que Bazel vuelva a ejecutar el comando. en la próxima compilación.

Un comando genrule no debe acceder a la red, excepto para conectar procesos que se elementos secundarios del comando, aunque actualmente esto no se aplica de manera forzosa.

El sistema de compilación borra automáticamente los archivos de salida existentes, pero crea los archivos superiores necesarios directorios antes de que ejecute una genrule. También quita todos los archivos de salida en caso de falla.

Consejos generales

• Asegúrate de que las herramientas ejecutadas por una genrule sean deterministas y herméticas. No deben escribir marcas de tiempo en su salida, y deben usar un orden estable para conjuntos y mapas, así como solo escribe rutas de acceso de archivo relativas al resultado, no rutas absolutas. Si no sigues esta regla, genera un comportamiento de compilación inesperado (Bazel no vuelve a compilar una genrule que pensabas que podría tener) y degradar el rendimiento de la caché.
• Usa $(location) ampliamente para resultados, herramientas y fuentes. Debido a la de archivos de salida para diferentes configuraciones, genrules no puede depender de un código y/o rutas absolutas.
• Escribe una macro de Starlark común en caso de que se usen genrules iguales o muy similares en varios lugares. Si la genrule es compleja, considera implementarla en una secuencia de comandos o como Regla de Estelaria. Esto mejora la legibilidad y la capacidad de prueba.
• Asegúrate de que el código de salida indique correctamente el éxito o el fracaso de la genrule.
• No escribas mensajes informativos en stdout ni stderr. Aunque es útil para la depuración, esto puede convertirse fácilmente en ruido; para que una genrule sea exitosa debe ser silenciosa. Por otro lado, una genrule con fallas debería emitir buenos mensajes de error.
• $$ evaluates to a $, a literal dollar-sign, so in order to invoke a shell command containing dollar-signs such as ls $(dirname $x), one must escape it thus: ls $$(dirname $$x).
• Evita crear symlinks y directorios. Bazel no copia el directorio o symlink. La estructura creada por genrules y su verificación de dependencias de directorios no son sólidas.
• Cuando hagas referencia a la genrule en otras reglas, podrás usar su etiqueta las etiquetas de los archivos de salida individuales. A veces, el único enfoque es más legible Otro: hacer referencia a los resultados por nombre en el srcs de una regla de consumo evitará Tomar involuntariamente otros resultados de la regla generativa, pero puede ser tedioso si esta produce muchas salidas.

Ejemplos

En este ejemplo, se genera foo.h. No hay fuentes, porque el comando no toma cualquier entrada. El "binario" que ejecuta el comando es una secuencia de comandos de Perl en el mismo paquete que genrule.

genrule(
    name = "foo",
    srcs = [],
    outs = ["foo.h"],
    cmd = "./$(location create_foo.pl) > \"$@\"",
    tools = ["create_foo.pl"],
)

En el siguiente ejemplo, se muestra cómo usar un filegroup y las salidas de otro genrule. Ten en cuenta que usar $(SRCS) en su lugar de directivas $(location) explícitas también funcionaría; este ejemplo usa el último para el solo fin de la demostración.

genrule(
    name = "concat_all_files",
    srcs = [
        "//some:files",  # a filegroup with multiple files in it ==> $(locations)
        "//other:gen",   # a genrule with a single output ==> $(location)
    ],
    outs = ["concatenated.txt"],
    cmd = "cat $(locations //some:files) $(location //other:gen) > $@",
)

Argumentos

test_suite

test_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, tests, visibility)

Un test_suite define un conjunto de pruebas que se consideran "útiles" a los humanos. Esta permite que los proyectos definan conjuntos de pruebas, como “pruebas que debes ejecutar antes del registro”, “nuestro pruebas de esfuerzo del proyecto" o "todas las pruebas pequeñas". El comando blaze test respeta este orden. de la organización: para una invocación como blaze test //some/test:suite, Blaze primero enumera todos los objetivos de prueba incluidos transitivamente en el objetivo //some/test:suite (se denominada "expansión del paquete de prueba"), luego Blaze compila y prueba esos objetivos.

Ejemplos

Un conjunto de pruebas para ejecutar todas las pruebas de nivel inferior en el paquete actual.

test_suite(
    name = "small_tests",
    tags = ["small"],
)

Un paquete de pruebas que ejecuta un conjunto específico de pruebas:

test_suite(
    name = "smoke_tests",
    tests = [
        "system_unittest",
        "public_api_unittest",
    ],
)

Un conjunto de pruebas para ejecutar todas las pruebas que no sean inestables en el paquete actual.

test_suite(
    name = "non_flaky_test",
    tags = ["-flaky"],
)

Argumentos