Se usó la API de Cloud Translation para traducir esta página.

Reglas generales

Reglas

alias
config_setting
grupo de archivos
genquery
genrule
starlark_doc_extract
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 pueda hacer referencia a la regla.

La asignación de alias solo funciona para objetivos “normales”. En particular, no se puede asignar un alias a package_group y test_suite.

La asignación de alias puede ser útil en repositorios grandes en los que cambiar el nombre de un destino requeriría realizar cambios en muchos archivos. También puedes usar una regla de alias para almacenar una llamada a la función select si deseas reutilizar esa lógica para varios objetivos.

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., se ignora "testonly" en el alias; en cambio, se usa el valor de solo prueba de la regla a la que se hace referencia), con algunas excepciones menores:

Las pruebas no se ejecutan si se menciona su alias en la línea de comandos. Para definir un alias que ejecute la prueba a la que se hace referencia, usa una regla test_suite con un solo destino en su atributo tests.
Cuando se definen grupos de entornos, no se admiten los alias para las reglas de environment. Tampoco se admiten en la opción de línea de comandos --target_environment.

Ejemplos

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

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

Argumentos

Atributos

name

Nombre (obligatorio)

Un nombre único para este destino.

actual

Etiqueta (obligatorio)

El objetivo al que hace referencia este alias. No es necesario que sea una regla, también puede ser un archivo de entrada.

config_setting

Ver la fuente de la regla

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) con el fin de activar atributos configurables. Consulta seleccionar para ver cómo consumir esta regla y atributos configurables para obtener una descripción general de la función general.

Ejemplos

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

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

El siguiente código coincide con cualquier compilación que se oriente a ARM y aplica 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"
      }
  )

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

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

Lo siguiente coincide con cualquier compilación que se oriente a una plataforma con una arquitectura x86_64 y una versión 2.25 de glibc, en el caso de que exista un constraint_value con la etiqueta //example:glibc_2_25. Ten en cuenta que una plataforma igual coincide si define valores de restricción adicionales aparte de estos dos.

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

En todos estos casos, es posible que la configuración cambie dentro de la compilación, por ejemplo, si es necesario compilar un destino para una plataforma diferente a la de su dependencia. Esto significa que, incluso cuando un objeto config_setting no coincide con las marcas de línea de comandos de nivel superior, puede coincidir con algunos objetivos de compilación.

Notas

Consulta select para ver lo que sucede cuando varios config_setting coinciden con el estado de la configuración actual.
Para las marcas que admiten formas abreviadas (p. ej., --compilation_mode frente a -c), las definiciones de values deben usar la forma completa. Estos coinciden automáticamente con las invocaciones con cualquiera de los formatos.
Si una marca toma varios valores (como --copt=-Da --copt=-Db o una marca de Starlark de tipo lista), values = { "flag": "a" } coincide si "a" está presente en cualquier lugar de la lista real.
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 las 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 que values = { "copt": "a,b" } coincide con el primero, pero no con el último). Sin embargo, --ios_multi_cpus (para las reglas de Apple) sí: -ios_multi_cpus=a,b y ios_multi_cpus=a --ios_multi_cpus=b producen ["a", "b"]. Revisa las definiciones de las marcas y prueba las condiciones con cuidado para verificar las expectativas exactas.
Si necesitas definir condiciones que no están modeladas con marcas de compilación integradas, usa las marcas definidas por Starlark. También puedes usar --define, pero esta opción ofrece una compatibilidad más débil y no se recomienda. Consulta este vínculo 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 se pueden usar en cualquier combinación en el mismo config_setting, pero se debe establecer al menos uno para cada config_setting.

Argumentos

Atributos
`name`	Nombre (obligatorio) Un nombre único para este destino.
`constraint_values`	Lista de etiquetas; no configurable; el valor predeterminado es `[]` El conjunto mínimo de `constraint_values` que la plataforma de destino debe especificar para que coincida con este `config_setting`. (la plataforma de ejecución no se considera aquí). Se ignorarán todos los valores de restricción adicionales que la plataforma haya ignorado. Consulta Atributos de compilación configurables para obtener más detalles. Si dos `config_setting` coinciden en el mismo `select`, este atributo no se considera para determinar si uno de los `config_setting` es una especialización del otro. En otras palabras, un `config_setting` no puede coincidir de manera más eficaz con una plataforma.
`define_values`	Diccionario: String -> String; no configurable; el valor predeterminado es `{}` Es lo mismo que `values`, pero, en particular, para la marca `--define`. `--define` es especial porque su sintaxis (`--define KEY=VAL`) significa que `KEY=VAL` es un valor desde la perspectiva de la marca de Bazel. Esto significa lo siguiente: config_setting( name = "a_and_b", values = { "define": "a=1", "define": "b=2", }) No funciona porque la misma clave (`define`) aparece dos veces en el diccionario. Este atributo resuelve ese problema: config_setting( name = "a_and_b", define_values = { "a": "1", "b": "2", }) coincide correctamente con `bazel build //foo --define a=1 --define b=2`. `--define` aún puede aparecer en `values` con una sintaxis de marca normal y se puede combinar libremente con este atributo, siempre que las claves del diccionario permanezcan distintas.
`flag_values`	Diccionario: etiqueta -> String; no configurable; el valor predeterminado es `{}` Igual que `values`, pero para marcas de compilación definidas por el usuario. Este es un atributo distinto porque se hace referencia a las marcas definidas por el usuario como etiquetas, mientras que a las marcas integradas se hace referencia como strings arbitrarias.
`values`	Diccionario: String -> String; no configurable; el valor predeterminado es `{}` El conjunto de valores de configuración que coinciden con esta regla (expresada como marcas de compilación) Esta regla hereda la configuración del destino configurado que hace referencia a él en una declaración `select`. Se considera que “coincide” con una invocación de Bazel si, para cada entrada en el diccionario, su configuración coincide con el valor esperado de la entrada. Por ejemplo, `values = {"compilation_mode": "opt"}` coincide con las invocaciones `bazel build --compilation_mode=opt ...` y `bazel build -c opt ...` en las reglas configuradas según el destino. Para mayor comodidad, los valores de configuración se especifican como marcas de compilación (sin el `"--"` anterior). Sin embargo, ten en cuenta que no son iguales. Esto se debe a que los destinos se pueden compilar en varias configuraciones dentro de la misma compilación. Por ejemplo, la “cpu” de una configuración ejecutiva coincide con el valor de `--host_cpu`, no de `--cpu`. Por lo tanto, diferentes instancias del mismo `config_setting` pueden coincidir con la misma invocación de manera diferente según la configuración de la regla que las usa. Si una marca no se configura explícitamente en la línea de comandos, se usa su valor predeterminado. Si una clave aparece varias veces en el diccionario, solo se usa la última instancia. Si una clave hace referencia a una marca que se puede configurar varias veces en la línea de comandos (p.ej., `bazel build --copt=foo --copt=bar --copt=baz ...`), se genera una coincidencia si alguna de esas opciones de configuración coincide.

grupo de archivos

Ver la fuente de la regla

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 un conjunto de objetivos. Luego, se puede hacer referencia a estas desde otras reglas.

Se recomienda el uso de filegroup en lugar de hacer referencia a directorios directamente. Este último no funciona correctamente, ya que el sistema de compilación no tiene pleno conocimiento de todos los archivos debajo del directorio, por lo que es posible que no se vuelva a compilar cuando estos archivos cambien. Cuando se combina con glob, filegroup puede garantizar que el sistema de compilación conozca explícitamente todos los archivos.

Ejemplos

Para crear un filegroup que consista en dos archivos fuente, haz lo siguiente:

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

O bien, usa un glob para expandir un directorio de datos de prueba:

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

Atributos
`name`	Nombre (obligatorio) Un nombre único para este destino.
`srcs`	Lista de etiquetas; el valor predeterminado es `[]` La lista de destinos que son miembros del grupo de archivos. Es común usar el resultado de una expresión glob para el valor del atributo `srcs`.
`data`	Lista de etiquetas; el valor predeterminado es `[]` La lista de archivos que necesita esta regla durante el tiempo de ejecución. Los destinos nombrados en el atributo `data` se agregarán a la `runfiles` de esta regla `filegroup`. Cuando se haga referencia a `filegroup` en el atributo `data` de otra regla, su `runfiles` se agregará al `runfiles` de la regla dependiente. Consulta la sección de dependencias de datos y la documentación general de `data` para obtener más información sobre cómo depender de los archivos de datos y usarlos.
`output_group`	String; el valor predeterminado es `""` El grupo de salida del cual se recopilarán los artefactos de las fuentes. Si se especifica este atributo, se exportarán los artefactos del grupo de salida especificado de las dependencias en lugar del grupo de salida predeterminado. Un “grupo de salida” es una categoría de artefactos de salida de un objetivo, que se especifica en la implementación de esa regla.

consulta generativa

Ver la fuente de la regla

genquery(name, deps, data, compatible_with, compressed_output, 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 lenguaje de consulta Blaze y vuelca el resultado en un archivo.

Para mantener la coherencia de la compilación, la consulta solo puede visitar el cierre transitivo de los destinos especificados en el atributo scope. Las consultas que infrinjan esta regla fallarán durante la ejecución si strict no se especifica o si es verdadero (si strict es falso, los destinos fuera del alcance solo se omitirán con una advertencia). La forma más fácil de asegurarte de que esto no suceda es mencionar las mismas etiquetas en el alcance y en la expresión de la consulta.

La única diferencia entre las consultas que se permiten aquí y en la línea de comandos es que aquí no se permiten las consultas que contienen especificaciones de destino con comodines (p.ej., //pkg:* o //pkg:all). Esto se debe a dos motivos: en primer lugar, porque genquery debe especificar un alcance para evitar que los objetivos fuera del cierre transitivo de la consulta influyan en su resultado y, en segundo lugar, porque los archivos BUILD no admiten dependencias con comodines (p.ej., no se permite deps=["//a/..."]).

Los resultados de la generación de consulta se ordenan de manera lexicográfica para aplicar los resultados deterministas, con la excepción de --output=graph|minrank|maxrank o cuando se usa somepath como la función de nivel superior.

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

Ejemplos

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

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

Argumentos

Atributos
`name`	Nombre (obligatorio) Un nombre único para este destino.
`compressed_output`	Booleano; el valor predeterminado es `False` Si es `True`, el resultado de la consulta se escribe en formato de archivo GZIP. Esta configuración se puede usar para evitar aumentos repentinos en el uso de memoria de Bazel cuando se espera que el resultado de la consulta sea grande. Bazel comprime internamente los resultados de las consultas de más de 2²⁰ bytes, sin importar el valor de esta configuración, por lo que establecerlo en `True` podría no reducir el montón retenido. Sin embargo, permite que Bazel omita la descompresión cuando escribe el archivo de salida, lo que puede requerir mucha memoria.
`expression`	String; obligatoria La consulta que se ejecutará. A diferencia de la línea de comandos y otros lugares en los archivos BUILD, las etiquetas aquí se resuelven en relación con el directorio raíz del lugar de trabajo. Por ejemplo, la etiqueta `:b` de este atributo en el archivo `a/BUILD` hará referencia al `//:b` de destino.
`opts`	Lista de cadenas; el valor predeterminado es `[]` Las opciones que se pasan al motor de consultas. Estas corresponden a las opciones de la línea de comandos que se pueden pasar a `bazel query`. Algunas opciones de consulta no están permitidas aquí: `--keep_going`, `--query_file`, `--universe_scope`, `--order_results` y `--order_output`. Las opciones que no se especifiquen aquí tendrán sus valores predeterminados al igual que en la línea de comandos de `bazel query`.
`scope`	Lista de etiquetas (obligatoria) El alcance de la consulta. No se permite que la consulta toque objetivos fuera del cierre transitivo de estos objetivos.
`strict`	Booleano; el valor predeterminado es `True` Si es verdadero, los destinos cuyas consultas escapen del cierre transitivo de sus permisos no se compilarán. Si es falso, Bazel imprimirá una advertencia y omitirá la ruta de acceso de la consulta que la haya llevado fuera del alcance, mientras completa el resto de la consulta.

genrule

Ver la fuente de la regla

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

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

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

Ten en cuenta que genrule requiere una shell para interpretar el argumento del comando. También es fácil hacer referencia a programas arbitrarios disponibles en la ruta de acceso; sin embargo, esto hace que el comando no sea hermético y es posible que no se pueda reproducir. Si solo necesitas ejecutar una herramienta, considera usar run_binary.

No uses una genrule para ejecutar pruebas. Hay dispensaciones especiales para las pruebas y los resultados de pruebas, 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 los genrules se ejecutan durante la compilación y en la arquitectura de ejecución (ambos pueden ser diferentes). Si necesitas una regla de prueba de uso general, 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 las pruebas. Considera el ejemplo de compilación de código C para un microcontrolador: el compilador acepta archivos de origen 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 compilarlo, pero el compilador C (si se compila desde la fuente) debe hacerlo.

El sistema de compilación usa la configuración de ejecución para describir las máquinas en las que se ejecuta la compilación y la configuración de destino a fin de describir las máquinas en las que se debe ejecutar el resultado de la compilación. Proporciona opciones para configurar cada una de ellas y separa los archivos correspondientes en directorios separados para evitar conflictos.

En el caso de los genrules, el sistema de compilación garantiza que las dependencias se compilen correctamente: se compilan srcs (si es necesario) para la configuración target, tools se compilan para la configuración exec, y se considera que el resultado corresponde a la configuración target. También proporciona variables "Make" que los comandos genrule pueden pasar a las herramientas correspondientes.

Es intencional que genrule no defina ningún atributo deps: otras reglas integradas usan metainformación dependiente del lenguaje que se pasa entre las reglas para determinar automáticamente cómo controlar las reglas dependientes, pero este nivel de automatización no es posible para las reglas de Genrules. Las Genrules funcionan únicamente a nivel de archivo y runfiles.

Casos especiales

Compilación ejecutable: En algunos casos, el sistema de compilación necesita ejecutar genrules para que la salida también se pueda ejecutar durante la compilación. Por ejemplo, si una genrule compila algún compilador personalizado que posteriormente usa otra genrule, el primero debe producir su salida para la configuración ejecutiva, 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 srcs y outs de la primera genrule para la configuración de ejecución en lugar de la configuración de destino. Consulta el manual del usuario para obtener más información.

Herramientas JDK y C++: Para usar una herramienta del JDK o el conjunto de compiladores de C++, el sistema de compilación proporciona un conjunto de variables para usar. Consulta Variable"Make" para obtener más detalles.

Entorno de Genrule

El comando genrule se ejecuta mediante una shell Bash configurada para fallar cuando un comando o una canalización falla, mediante set -e -o pipefail.

La herramienta de compilación ejecuta el comando Bash en un entorno de proceso depurado que define solo variables principales como PATH, PWD, TMPDIR, entre otras. Para garantizar que las compilaciones sean reproducibles, la mayoría de las variables definidas en el entorno de 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 siguiente compilación.

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

El sistema de compilación borra automáticamente cualquier archivo de salida existente, pero crea los directorios superiores necesarios antes de ejecutar una genrule. También quita cualquier archivo de salida en caso de una 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 el resultado y deben usar un orden estable para los conjuntos y mapas, así como escribir solo rutas de acceso relativas a archivos en el resultado, ninguna ruta de acceso absoluta. No seguir esta regla generará un comportamiento de compilación inesperado (Bazel no volverá a compilar una genrule que pensabas que lo haría) y degradará el rendimiento de la caché.
Usa $(location) de manera exhaustiva para resultados, herramientas y fuentes. Debido a la segregación de los archivos de salida para diferentes configuraciones, las genrules no pueden depender de rutas codificadas o absolutas.
Escribe una macro de Starlark común en caso de que se usen reglas iguales o muy similares en varios lugares. Si la genrule es compleja, considera implementarla en una secuencia de comandos o como una regla de Starlark. 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 a stdout ni stderr. Si bien es útil para la depuración, esto puede convertirse fácilmente en ruido; una genrule exitosa debe ser silenciosa. Por otro lado, una genrule que falla debe emitir mensajes de error correctos.
$$ 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 la estructura de directorio/symlink que crea genrules y su verificación de dependencias de directorios no está bien.
Cuando haces referencia a genrule en otras reglas, puedes usar la etiqueta de la regla o las etiquetas de archivos de salida individuales. A veces, un enfoque es más legible y, a veces, el otro: hacer referencia a salidas por nombre en el srcs de una regla de consumo evitará seleccionar otras salidas de la regla de consumo por error, 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 ninguna entrada. El “binario” que ejecuta el comando es una secuencia de comandos 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 los resultados de otro genrule. Ten en cuenta que el uso de $(SRCS) en lugar de directivas $(location) explícitas también funcionaría; en este ejemplo, se usan estas últimas a modo de 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

Atributos
`name`	Nombre (obligatorio) Un nombre único para este destino. Puedes hacer referencia a esta regla por su nombre en la sección `srcs` o `deps` de otras reglas `BUILD`. Si la regla genera archivos de origen, debes usar el atributo `srcs`.
`srcs`	Lista de etiquetas; el valor predeterminado es `[]` Una lista de entradas para esta regla, como los archivos de origen que se procesarán. Este atributo no es adecuado para enumerar las herramientas que ejecuta `cmd`. En su lugar, usa el atributo `tools` para ellas. El sistema de compilación garantiza que estos requisitos previos se compilen antes de ejecutar el comando genrule y usa la misma configuración que la solicitud de compilación original. Los nombres de los archivos de estos requisitos previos están disponibles para el comando como una lista separada por espacios en `$(SRCS)`. Como alternativa, la ruta de acceso de un `//x:y` de destino `srcs` individual se puede obtener usando `$(location //x:y)` o `$<`, siempre que sea la única entrada en `srcs`.
`outs`	Lista de nombres de archivo; no configurable; obligatorio Lista de archivos que genera esta regla. Los archivos de salida no deben cruzar los límites del paquete. Los nombres de los archivos de salida se interpretan como relacionados con el paquete. Si se configura la marca `executable`, `outs` debe contener exactamente una etiqueta. Se espera que el comando genrule cree cada archivo de salida en una ubicación predeterminada. La ubicación está disponible en `cmd` con variables "Make" específicas de las reglas de género (`$@`, `$(OUTS)`, `$(@D)` o `$(RULEDIR)`) o con la sustitución `$(location)`.
`cmd`	String; el valor predeterminado es `""` El comando que se ejecutará. Sujeto a la sustitución de la variable `$(location)` y “Make”. Se aplica la primera sustitución de `$(location)` y se reemplazan todas las ocurrencias de `$(location label)` y `$(locations label)` (y construcciones similares que usan variables relacionadas `execpath`, `execpaths`, `rootpath` y `rootpaths`). A continuación, se expanden las variables"Make". Ten en cuenta que las variables predefinidas `$(JAVA)`, `$(JAVAC)` y `$(JAVABASE)` se expanden en la configuración exec, por lo que las invocaciones de Java que se ejecutan como parte de un paso de compilación pueden cargar correctamente bibliotecas compartidas y otras dependencias. Por último, el comando resultante se ejecuta con la shell Bash. Si el código de salida no es cero, se considera que el comando falló. Este es el resguardo de `cmd_bash`, `cmd_ps` y `cmd_bat`, si ninguno de ellos es aplicable. Si la longitud de la línea de comandos supera el límite de la plataforma (64 K en Linux/macOS y 8K en Windows), genrule escribirá el comando en una secuencia de comandos y la ejecutará para solucionar el problema. Esto se aplica a todos los atributos cmd (`cmd`, `cmd_bash`, `cmd_ps`, `cmd_bat`).
`cmd_bash`	String; el valor predeterminado es `""` El comando Bash que se ejecutará. Este atributo tiene mayor prioridad que `cmd`. El comando se expande y se ejecuta de la misma manera que el atributo `cmd`.
`cmd_bat`	String; el valor predeterminado es `""` El comando por lotes para ejecutar en Windows. Este atributo tiene mayor prioridad que `cmd` y `cmd_bash`. El comando se ejecuta de la misma manera que el atributo `cmd`, con las siguientes diferencias: Este atributo solo se aplica en Windows. El comando se ejecuta con `cmd.exe /c` y los siguientes argumentos predeterminados: `/S`: Quita las primeras y las últimas comillas, y ejecuta todo lo demás tal como está. `/E:ON`: Habilita el conjunto de comandos extendido. `/V:ON`: Habilita la expansión variable retrasada. `/D`: Ignora las entradas del registro de AutoRun. Después de la sustitución $(location) y “Make” variable, las rutas de acceso se expandirán a las rutas de estilo de Windows (con barra inversa).
`cmd_ps`	String; el valor predeterminado es `""` El comando de PowerShell para ejecutar en Windows. Este atributo tiene mayor prioridad que `cmd`, `cmd_bash` y `cmd_bat`. El comando se ejecuta de manera similar al atributo `cmd`, con las siguientes diferencias: Este atributo solo se aplica en Windows. El comando se ejecuta con `powershell.exe /c`. Para que PowerShell sea más fácil de usar y menos propenso a errores, ejecutamos los siguientes comandos para configurar el entorno antes de ejecutar el comando de Powershell en genrule. `Set-ExecutionPolicy -Scope CurrentUser RemoteSigned`: Permite ejecutar secuencias de comandos sin firmar. `$errorActionPreference='Stop'`: En caso de que haya varios comandos separados por `;`, la acción finaliza de inmediato si falla un CmdLet de PowerShell, pero NO funciona para un comando externo. `$PSDefaultParameterValues['*:Encoding'] = 'utf8'`: Cambia la codificación predeterminada de utf-16 a utf-8.
`executable`	Booleano; no configurable; el valor predeterminado es `False` Declara el resultado como ejecutable. Si estableces esta marca como verdadera, el resultado es un archivo ejecutable y se puede ejecutar con el comando `run`. En este caso, la genrule debe producir exactamente una salida. Si se establece este atributo, `run` intentará ejecutar el archivo independientemente de su contenido. No se admite la declaración de dependencias de datos para el ejecutable generado.
`local`	Booleano; el valor predeterminado es `False` Si se configura como verdadera, esta opción fuerza la ejecución de `genrule` con la estrategia “local”, lo que significa que no hay ejecución remota, zona de pruebas ni trabajadores persistentes. Esto equivale a proporcionar "local" como etiqueta (`tags=["local"]`).
`message`	String; el valor predeterminado es `""` Un mensaje de progreso. Un mensaje de progreso que se imprimirá a medida que se ejecute este paso de compilación. De forma predeterminada, el mensaje es "Generando salida" (o un resultado similar), pero puedes proporcionar uno más específico. Usa este atributo en lugar de `echo` o de otras instrucciones de impresión en el comando `cmd`, ya que permite que la herramienta de compilación controle si se imprimen o no esos mensajes de progreso.
`output_licenses`	Tipo de licencia; el valor predeterminado es `["none"]` Consulta `common attributes`.
`output_to_bindir`	Booleano; no configurable; el valor predeterminado es `False` Si se configura como verdadera, esta opción hace que los archivos de salida se escriban en el directorio `bin` en lugar del directorio `genfiles`.
`tools`	Lista de etiquetas; el valor predeterminado es `[]` Una lista de dependencias tool para esta regla. Consulta la definición de dependencias para obtener más información. El sistema de compilación garantiza que estos requisitos previos se compilen antes de ejecutar el comando genrule y usan la configuración exec, ya que estas herramientas se ejecutan como parte de la compilación. La ruta de un `//x:y` de destino `tools` individual se puede obtener mediante `$(location //x:y)`. Para garantizar que se compilen con la configuración correcta, cualquier `*_binary` o herramienta que ejecute `cmd` debe aparecer en esta lista, no en `srcs`.

starlark_doc_extract

Ver la fuente de la regla

starlark_doc_extract(name, deps, src, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, render_main_repo_name, restricted_to, symbol_names, tags, target_compatible_with, testonly, visibility)

starlark_doc_extract() extrae documentación para reglas, funciones (incluidas las macros), aspectos y proveedores definidos o que se vuelven a exportar en un archivo .bzl o .scl determinado. El resultado de esta regla es un proto binario ModuleInfo, como se define en stardoc_output.proto en el árbol de fuentes de Bazel.

Objetivos de salida implícitos

name.binaryproto (el resultado predeterminado): Un proto binario ModuleInfo.
name.textproto (solo se compila si se solicita explícitamente): Es la versión proto de texto de name.binaryproto.

Advertencia: No se garantiza que el formato de salida de esta regla sea estable. Está destinado principalmente para el uso interno de Stardoc.

Argumentos

Atributos
`name`	Nombre (obligatorio) Un nombre único para este destino.
`deps`	Lista de etiquetas; el valor predeterminado es `[]` Es una lista de destinos que unen los archivos de Starlark vinculados con `src` mediante `load()`. En el uso normal, estos objetivos deben ser `bzl_library`, pero la regla `starlark_doc_extract` no lo aplica y acepta cualquier destino que proporcione archivos de Starlark en su `DefaultInfo`. Ten en cuenta que los archivos de Starlark unidos deben ser archivos del árbol de fuentes; Bazel no puede utilizar archivos generados con `load()`.
`src`	Etiqueta (obligatorio) Un archivo de Starlark del que se extrae la documentación. Ten en cuenta que este debe ser un archivo en el árbol de fuentes; Bazel no puede `load()` los archivos generados.
`render_main_repo_name`	Booleano; el valor predeterminado es `False` Si es verdadero, procesa las etiquetas en el repositorio principal en la documentación emitida con un componente de repositorio (en otras palabras, `//foo:bar.bzl` se emitirá como `@main_repo_name//foo:bar.bzl`). El nombre que se usará para el repositorio principal se obtiene de `module(name = ...)` en el archivo `MODULE.bazel` del repositorio principal (si Bzlmod está habilitado) o de `workspace(name = ...)` en el archivo `WORKSPACE` del repositorio principal. Este atributo se debe establecer en `False` cuando se genere documentación para archivos de Starlark que se usará solo dentro del mismo repositorio, y en `True` cuando se genere documentación de archivos de Starlark que se usarán desde otros repositorios.
`symbol_names`	Lista de cadenas; el valor predeterminado es `[]` Una lista opcional de nombres calificados de funciones, reglas, proveedores o aspectos exportados (o estructuras en las que están anidados) para los que se extrae la documentación. En este caso, nombre calificado hace referencia al nombre con el que una entidad se pone a disposición de un usuario del módulo, incluidos los structs en los que la entidad está anidada para el espacio de nombres. `starlark_doc_extract` emite documentación para una entidad solo si cada componente del nombre calificado de la entidad es público (en otras palabras, el primer carácter de cada componente del nombre calificado es alfabético, no `"_"`); y ya sea que la lista `symbol_names` esté vacía (que es el caso predeterminado) o El nombre calificado de la entidad, o el nombre calificado de una estructura en la que está anidada la entidad, se encuentra en la lista `symbol_names`.

test_suite

Ver la fuente de la regla

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" para los humanos. Esto permite que los proyectos definan conjuntos de pruebas, como “pruebas que debes ejecutar antes de registrar”, “pruebas de esfuerzo de nuestro proyecto” o “todas las pruebas pequeñas”. El comando blaze test respeta este tipo de organización: para una invocación como blaze test //some/test:suite, Blaze primero enumera todos los destinos de prueba incluidos de forma transitiva por el destino //some/test:suite (llamado “expansión de test_suite”) y, luego, Blaze compila y prueba esos objetivos.

Ejemplos

Un paquete de pruebas para ejecutar todas las pruebas pequeñas 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 paquete de pruebas para ejecutar todas las pruebas en el paquete actual que no son inestables.

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

Argumentos

Atributos

name

Nombre (obligatorio)

Un nombre único para este destino.

tags

Lista de strings; no configurable; el valor predeterminado es []

Lista de etiquetas de texto, como “pequeño” o “base de datos” o “-poco” Las etiquetas pueden ser cualquier cadena válida.

Las etiquetas que comienzan con el carácter "-" se consideran etiquetas negativas. El carácter "-" anterior no se considera parte de la etiqueta, por lo que una etiqueta de conjunto "-small" coincide con el tamaño "pequeño" de una prueba. Todas las demás etiquetas se consideran positivas.

De manera opcional, para que las etiquetas positivas sean más explícitas, las etiquetas también pueden comenzar con el carácter "+", que no se evaluará como parte del texto de la etiqueta. Solo hace que la distinción positiva y negativa sea más fácil de leer.

En el conjunto de pruebas, solo se incluirán las reglas de prueba que coincidan con todas las etiquetas positivas y ninguna de las etiquetas negativas. Ten en cuenta que esto no significa que se omite la comprobación de errores de las dependencias de las pruebas filtradas; las dependencias de las pruebas omitidas deben ser legales (p.ej., no estar bloqueadas por las restricciones de visibilidad).

La palabra clave de la etiqueta manual se trata de manera diferente a la anterior por la “expansión test_suite” que realiza el comando blaze test en invocaciones que involucran patrones de destino comodín. Allí, los destinos test_suite etiquetados como "manuales" se filtran (y, por lo tanto, no se expanden). Este comportamiento es coherente con la forma en que blaze build y blaze test manejan patrones de destino comodín en general. Ten en cuenta que esto es explícitamente diferente del comportamiento de blaze query 'tests(E)', ya que la función de consulta tests siempre expande los paquetes, sin importar la etiqueta manual.

Ten en cuenta que el elemento size de una prueba se considera una etiqueta para el filtrado.

Si necesitas un test_suite que contenga pruebas con etiquetas mutuamente excluyentes (p.ej., todas las pruebas pequeñas y medianas), deberás crear tres reglas de test_suite: una para todas las pruebas pequeñas, una para todas las pruebas de nivel intermedio y otra para las dos anteriores.

tests

Lista de etiquetas; no configurable; el valor predeterminado es []

Una lista de paquetes de pruebas y objetivos de prueba de cualquier idioma.

Aquí se acepta cualquier *_test, independientemente del idioma. Sin embargo, no se aceptan objetivos *_binary, incluso si ejecutan una prueba. Solo se filtra por el tags especificado para las pruebas enumeradas directamente en este atributo. Si este atributo contiene elementos test_suite, las pruebas que contiene no se filtrarán con este test_suite (ya se consideran filtradas).

Si el atributo tests no se especifica o está vacío, la regla incluirá de forma predeterminada todas las reglas de prueba del archivo BUILD actual que no estén etiquetadas como manual. Estas reglas siguen sujetas al filtro tag.