Funciones

Contenido

paquete

package(default_deprecation, default_package_metadata, default_testonly, default_visibility, features)

Esta función declara metadatos que se aplican a todas las reglas del paquete. Se usa como máximo una vez dentro de un paquete (archivo BUILD).

Para la contraparte que declara metadatos que se aplican a cada regla en todo el repositorio, usa la función repo() en el archivo REPO.bazel en la raíz de tu repositorio. La función repo() toma exactamente los mismos argumentos que package().

Se debe llamar a la función package() justo después de todas las declaraciones load() en la parte superior del archivo, antes de cualquier regla.

Argumentos

Atributo Descripción
default_applicable_licenses

Alias de default_package_metadata.

default_visibility

Lista de etiquetas; el valor predeterminado es []

Es la visibilidad predeterminada de los destinos de reglas de nivel superior y las macros simbólicas de este paquete, es decir, los destinos y las macros simbólicas que no se declaran dentro de una macro simbólica. Este atributo se ignora si el destino o la macro especifican un valor visibility.

Para obtener información detallada sobre la sintaxis de este atributo, consulta la documentación de visibility. La visibilidad predeterminada del paquete no se aplica a exports_files, que es público de forma predeterminada.

default_deprecation

String; el valor predeterminado es ""

Establece el mensaje deprecation predeterminado para todas las reglas de este paquete.

default_package_metadata

Lista de etiquetas; el valor predeterminado es []

Establece una lista predeterminada de destinos de metadatos que se aplican a todos los demás destinos del paquete. Por lo general, estos son destinos relacionados con las declaraciones de licencias y paquetes de OSS. Consulta rules_license para ver ejemplos.

default_testonly

Booleano; el valor predeterminado es False, excepto como se indica

Establece la propiedad predeterminada testonly para todas las reglas de este paquete.

En los paquetes de javatests, el valor predeterminado es True.

features

Cadenas de lista; el valor predeterminado es []

Establece varias marcas que afectan la semántica de este archivo BUILD.

Esta función la usan principalmente las personas que trabajan en el sistema de compilación para etiquetar paquetes que necesitan algún tipo de manejo especial. No uses esta opción, a menos que lo solicite de forma explícita alguien que trabaje en el sistema de compilación.

Ejemplos

La siguiente declaración indica que las reglas de este paquete solo son visibles para los miembros del grupo de paquetes //foo:target. Las declaraciones de visibilidad individuales en una regla, si están presentes, anulan esta especificación.
package(default_visibility = ["//foo:target"])

package_group

package_group(name, packages, includes)

Esta función define un conjunto de paquetes y asocia una etiqueta con el conjunto. Se puede hacer referencia a la etiqueta en los atributos visibility.

Los grupos de paquetes se usan principalmente para controlar la visibilidad. Se puede hacer referencia a un destino visible de forma pública desde cada paquete del árbol de fuentes. Un destino visible de forma privada solo se puede referenciar dentro de su propio paquete (no en subpaquetes). Entre estos extremos, un destino puede permitir el acceso a su propio paquete y a cualquiera de los paquetes descritos por uno o más grupos de paquetes. Para obtener una explicación más detallada del sistema de visibilidad, consulta el atributo visibility.

Se considera que un paquete determinado está en el grupo si coincide con el atributo packages o si ya está incluido en uno de los otros grupos de paquetes mencionados en el atributo includes.

Los grupos de paquetes son técnicamente destinos, pero no se crean con reglas y no tienen ninguna protección de visibilidad.

Argumentos

Atributo Descripción
name

Nombre; obligatorio

Es un nombre único para este destino.

packages

Lista de cadenas; el valor predeterminado es []

Es una lista de cero o más especificaciones de paquetes.

Cada cadena de especificación de paquete puede tener uno de los siguientes formatos:

  1. Es el nombre completo de un paquete, sin su repositorio, que comienza con una barra doble. Por ejemplo, //foo/bar especifica el paquete que tiene ese nombre y que se encuentra en el mismo repositorio que el grupo de paquetes.
  2. Igual que el anterior, pero con un /... final. Por ejemplo, //foo/... especifica el conjunto de //foo y todos sus subpaquetes. //... especifica todos los paquetes del repositorio actual.
  3. Las cadenas public o private, que especifican, respectivamente, todos los paquetes o ningún paquete (Este formato requiere que se establezca la marca --incompatible_package_group_has_public_syntax).

Además, los primeros dos tipos de especificaciones de paquetes también pueden tener el prefijo - para indicar que se niegan.

El grupo de paquetes contiene cualquier paquete que coincida con al menos una de sus especificaciones positivas y ninguna de sus especificaciones negativas. Por ejemplo, el valor [//foo/..., -//foo/tests/...] incluye todos los subpaquetes de //foo que no son también subpaquetes de //foo/tests. (Se incluye //foo, pero no //foo/tests).

Aparte de la visibilidad pública, no hay forma de especificar directamente paquetes fuera del repositorio actual.

Si falta este atributo, es lo mismo que establecerlo en una lista vacía, que también es lo mismo que establecerlo en una lista que solo contenga private.

Nota: Antes de Bazel 6.0, la especificación //... tenía un comportamiento heredado de ser igual a public. Este comportamiento se corrige cuando se habilita --incompatible_fix_package_group_reporoot_syntax, que es el valor predeterminado después de Bazel 6.0.

Nota: Antes de Bazel 6.0, cuando este atributo se serializa como parte de bazel query --output=proto (o --output=xml), se omiten las barras iniciales. Por ejemplo, //pkg/foo/... se mostrará como \"pkg/foo/...\". Este comportamiento se corrige cuando se habilita --incompatible_package_group_includes_double_slash, que es el valor predeterminado después de Bazel 6.0.

includes

Lista de etiquetas; el valor predeterminado es []

Son otros grupos de paquetes que se incluyen en este.

Las etiquetas de este atributo deben hacer referencia a otros grupos de paquetes. Se considera que los paquetes de los grupos de paquetes a los que se hace referencia forman parte de este grupo de paquetes. Esto es transitivo: si el grupo de paquetes a incluye el grupo de paquetes b y b incluye el grupo de paquetes c, cada paquete de c también será miembro de a.

Cuando se usa junto con especificaciones de paquetes con negación, ten en cuenta que el conjunto de paquetes para cada grupo se calcula primero de forma independiente y, luego, se unen los resultados. Esto significa que las especificaciones negadas en un grupo no tienen efecto en las especificaciones de otro grupo.

Ejemplos

La siguiente declaración package_group especifica un grupo de paquetes llamado "tropical" que contiene frutas tropicales.

package_group(
    name = "tropical",
    packages = [
        "//fruits/mango",
        "//fruits/orange",
        "//fruits/papaya/...",
    ],
)

En las siguientes declaraciones, se especifican los grupos de paquetes de una aplicación ficticia:

package_group(
    name = "fooapp",
    includes = [
        ":controller",
        ":model",
        ":view",
    ],
)

package_group(
    name = "model",
    packages = ["//fooapp/database"],
)

package_group(
    name = "view",
    packages = [
        "//fooapp/swingui",
        "//fooapp/webui",
    ],
)

package_group(
    name = "controller",
    packages = ["//fooapp/algorithm"],
)

exports_files

exports_files([label, ...], visibility, licenses)

exports_files() especifica una lista de archivos que pertenecen a este paquete y que se exportan a otros paquetes.

El archivo BUILD de un paquete solo puede hacer referencia directa a los archivos de origen que pertenecen a otro paquete si se exportan de forma explícita con una declaración exports_files(). Obtén más información sobre la visibilidad de los archivos.

Como comportamiento heredado, los archivos mencionados como entrada para una regla también se exportan con la visibilidad predeterminada hasta que se cambia la marca --incompatible_no_implicit_file_export. Sin embargo, no se debe confiar en este comportamiento y se debe migrar de forma activa.

Argumentos

El argumento es una lista de nombres de archivos dentro del paquete actual. También se puede especificar una declaración de visibilidad. En este caso, los archivos serán visibles para los destinos especificados. Si no se especifica la visibilidad, los archivos serán visibles para todos los paquetes, incluso si se especificó una visibilidad predeterminada del paquete en la función package. También se pueden especificar las licencias.

Ejemplo

En el siguiente ejemplo, se exporta golden.txt, un archivo de texto del paquete test_data, para que otros paquetes puedan usarlo, por ejemplo, en el atributo data de las pruebas.

# from //test_data/BUILD

exports_files(["golden.txt"])

glob

glob(include, exclude=[], exclude_directories=1, allow_empty=True)

Glob es una función auxiliar que busca todos los archivos que coinciden con ciertos patrones de ruta de acceso y devuelve una lista nueva, mutable y ordenada de sus rutas de acceso. Glob solo busca archivos en su propio paquete y solo busca archivos de origen (no archivos generados ni otros destinos).

La etiqueta de un archivo de origen se incluye en el resultado si la ruta de acceso relativa al paquete del archivo coincide con cualquiera de los patrones include y ninguno de los patrones exclude.

Las listas include y exclude contienen patrones de ruta de acceso que son relativos al paquete actual. Cada patrón puede constar de uno o más segmentos de ruta de acceso. Como es habitual con las rutas de Unix, estos segmentos están separados por /. Los segmentos del patrón se comparan con los segmentos de la ruta de acceso. Los segmentos pueden contener el comodín *, que coincide con cualquier subcadena del segmento de ruta (incluso la subcadena vacía), excepto el separador de directorio /. Este comodín se puede usar varias veces dentro de un segmento de ruta de acceso. Además, el comodín ** puede coincidir con cero o más segmentos de ruta de acceso completos, pero se debe declarar como un segmento de ruta de acceso independiente.

Ejemplos:
  • foo/bar.txt coincide exactamente con el archivo foo/bar.txt en este paquete (a menos que foo/ sea un subpaquete)
  • foo/*.txt coincide con todos los archivos del directorio foo/ si el archivo termina con .txt (a menos que foo/ sea un subpaquete).
  • foo/a*.htm* coincide con todos los archivos del directorio foo/ que comienzan con a, luego tienen una cadena arbitraria (podría estar vacía), luego tienen .htm y terminan con otra cadena arbitraria (a menos que foo/ sea un subpaquete), como foo/axx.htm y foo/a.html o foo/axxx.html.
  • foo/* coincide con todos los archivos del directorio foo/ (a menos que foo/ sea un subpaquete); no coincide con el directorio foo en sí, incluso si exclude_directories se establece en 0
  • foo/** coincide con todos los archivos de cada subdirectorio que no sea un subpaquete en el subdirectorio de primer nivel del paquete foo/; si exclude_directories se establece en 0, el directorio foo también coincide con el patrón; en este caso, se considera que ** coincide con cero segmentos de ruta
  • **/a.txt coincide con los archivos a.txt del directorio de este paquete y los subdirectorios que no son subpaquetes.
  • **/bar/**/*.txt coincide con cada archivo .txt en cada subdirectorio que no sea un subpaquete de este paquete, si al menos un directorio de la ruta de acceso resultante se llama bar, como xxx/bar/yyy/zzz/a.txt o bar/a.txt (recuerda que ** también coincide con cero segmentos) o bar/zzz/a.txt
  • ** coincide con todos los archivos de todos los subdirectorios que no son subpaquetes de este paquete.
  • foo**/a.txt es un patrón no válido, ya que ** debe aparecer solo como un segmento
  • foo/ es un patrón no válido, ya que el segundo segmento definido después de / es una cadena vacía

Si el argumento exclude_directories está habilitado (establecido en 1), los archivos de tipo directorio se omitirán de los resultados (el valor predeterminado es 1).

Si el argumento allow_empty se establece en False, la función glob arrojará un error si el resultado es la lista vacía.

Existen varias limitaciones y advertencias importantes:

  1. Dado que glob() se ejecuta durante la evaluación del archivo BUILD, glob() solo coincide con los archivos de tu árbol de fuentes, nunca con los archivos generados. Si compilas un destino que requiere archivos de origen y generados, debes agregar una lista explícita de archivos generados al glob. Consulta el ejemplo que se incluye más abajo con :mylib y :gen_java_srcs.

  2. Si una regla tiene el mismo nombre que un archivo de origen coincidente, la regla "ocultará" el archivo.

    Para comprender esto, recuerda que glob() devuelve una lista de rutas de acceso, por lo que usar glob() en el atributo de otras reglas (p.ej., srcs = glob(["*.cc"])) tiene el mismo efecto que enumerar las rutas de acceso que coinciden de forma explícita. Por ejemplo, si glob() genera ["Foo.java", "bar/Baz.java"], pero también hay una regla en el paquete llamada "Foo.java" (que está permitida, aunque Bazel advierte sobre ella), el consumidor de glob() usará la regla "Foo.java" (sus resultados) en lugar del archivo "Foo.java". Consulta el problema #10395 de GitHub para obtener más detalles.

  3. Los globs pueden coincidir con archivos en subdirectorios. Y los nombres de los subdirectorios pueden tener comodines. Sin embargo…
  4. No se permite que las etiquetas crucen el límite del paquete, y glob no coincide con los archivos de los subpaquetes.

    Por ejemplo, la expresión glob **/*.cc en el paquete x no incluye x/y/z.cc si x/y existe como un paquete (ya sea como x/y/BUILD o en algún otro lugar de la ruta de acceso del paquete). Esto significa que el resultado de la expresión glob en realidad depende de la existencia de archivos BUILD, es decir, la misma expresión glob incluiría x/y/z.cc si no hubiera un paquete llamado x/y o si se marcara como borrado con la marca --deleted_packages.

  5. La restricción anterior se aplica a todas las expresiones glob, sin importar qué comodines usen.
  6. Un archivo oculto cuyo nombre comienza con . coincide por completo con los comodines ** y *. Si quieres que un archivo oculto coincida con un patrón compuesto, este debe comenzar con un .. Por ejemplo, * y .*.txt coincidirán con .foo.txt, pero *.txt no lo hará. Los directorios ocultos también se hacen coincidir de la misma manera. Los directorios ocultos pueden incluir archivos que no se requieren como entradas y pueden aumentar la cantidad de archivos agrupados innecesariamente y el consumo de memoria. Para excluir directorios ocultos, agrégalos al argumento de la lista "exclude".
  7. El comodín "**" tiene un caso límite: el patrón "**" no coincide con la ruta de acceso del directorio del paquete. Es decir, glob(["**"], exclude_directories = False) coincide con todos los archivos y directorios de forma transitiva estrictamente en el directorio del paquete actual (pero, por supuesto, no en los directorios de los subpaquetes; consulta la nota anterior al respecto).

En general, debes intentar proporcionar una extensión adecuada (p.ej., *.html) en lugar de usar un asterisco (*) solo para un patrón de glob. El nombre más explícito se autodocumenta y garantiza que no coincida accidentalmente con archivos de copia de seguridad o archivos de guardado automático de emacs/vi/…

Cuando escribes reglas de compilación, puedes enumerar los elementos del glob. Esto permite, por ejemplo, generar reglas individuales para cada entrada. Consulta la sección Ejemplo de glob expandido que aparece más abajo.

Ejemplos de glob

Crea una biblioteca de Java compilada a partir de todos los archivos Java de este directorio y todos los archivos generados por la regla :gen_java_srcs.

java_library(
    name = "mylib",
    srcs = glob(["*.java"]) + [":gen_java_srcs"],
    deps = "...",
)

genrule(
    name = "gen_java_srcs",
    outs = [
        "Foo.java",
        "Bar.java",
    ],
    ...
)

Incluye todos los archivos txt del directorio testdata, excepto experimental.txt. Ten en cuenta que no se incluirán los archivos de los subdirectorios de testdata. Si quieres que se incluyan esos archivos, usa un glob recursivo (**).

sh_test(
    name = "mytest",
    srcs = ["mytest.sh"],
    data = glob(
        ["testdata/*.txt"],
        exclude = ["testdata/experimental.txt"],
    ),
)

Ejemplos de glob recursivo

Haz que la prueba dependa de todos los archivos txt del directorio testdata y de cualquiera de sus subdirectorios (y sus subdirectorios, etcétera). Se ignoran los subdirectorios que contienen un archivo BUILD. (Consulta las limitaciones y advertencias anteriores).

sh_test(
    name = "mytest",
    srcs = ["mytest.sh"],
    data = glob(["testdata/**/*.txt"]),
)

Crea una biblioteca compilada a partir de todos los archivos Java de este directorio y todos los subdirectorios, excepto aquellos cuya ruta de acceso incluya un directorio llamado testing. Si es posible, se debe evitar este patrón, ya que puede reducir la incrementalidad de la compilación y, por lo tanto, aumentar los tiempos de compilación.

java_library(
    name = "mylib",
    srcs = glob(
        ["**/*.java"],
        exclude = ["**/testing/**"],
    ),
)

Ejemplos de glob expandidos

Crea una genrule individual para *_test.cc en el directorio actual que cuente la cantidad de líneas del archivo.

# Conveniently, the build language supports list comprehensions.
[genrule(
    name = "count_lines_" + f[:-3],  # strip ".cc"
    srcs = [f],
    outs = ["%s-linecount.txt" % f[:-3]],
    cmd = "wc -l $< >$@",
 ) for f in glob(["*_test.cc"])]

Si el archivo BUILD anterior está en el paquete //foo y el paquete contiene tres archivos coincidentes, a_test.cc, b_test.cc y c_test.cc, la ejecución de bazel query '//foo:all' mostrará todas las reglas que se generaron:

$ bazel query '//foo:all' | sort
//foo:count_lines_a_test
//foo:count_lines_b_test
//foo:count_lines_c_test

seleccionar

select(
    {conditionA: valuesA, conditionB: valuesB, ...},
    no_match_error = "custom message"
)

select() es la función auxiliar que hace que un atributo de regla sea configurable. Puede reemplazar el lado derecho de casi cualquier asignación de atributos para que su valor dependa de las marcas de Bazel de la línea de comandos. Puedes usar esto, por ejemplo, para definir dependencias específicas de la plataforma o para incorporar diferentes recursos según si una regla se compila en el modo "desarrollador" o "versión".

El uso básico es el siguiente:

sh_binary(
    name = "mytarget",
    srcs = select({
        ":conditionA": ["mytarget_a.sh"],
        ":conditionB": ["mytarget_b.sh"],
        "//conditions:default": ["mytarget_default.sh"]
    })
)

Esto hace que el atributo srcs de un sh_binary se pueda configurar reemplazando su asignación de lista de etiquetas normal por una llamada a select que asigna condiciones de configuración a valores coincidentes. Cada condición es una referencia de etiqueta a un config_setting o constraint_value, que "coincide" si la configuración del destino coincide con un conjunto de valores esperado. Luego, el valor de mytarget#srcs se convierte en la lista de etiquetas que coincida con la invocación actual.

Notas:

  • Se selecciona exactamente una condición en cualquier invocación.
  • Si coinciden varias condiciones y una es una especialización de las otras, la especialización tiene prioridad. La condición B se considera una especialización de la condición A si B tiene las mismas marcas y valores de restricción que A, además de algunas marcas o valores de restricción adicionales. Esto también significa que la resolución de especialización no está diseñada para crear un orden, como se demuestra en el ejemplo 2 que aparece a continuación.
  • Si coinciden varias condiciones y una no es una especialización de todas las demás, Bazel falla con un error, a menos que todas las condiciones se resuelvan con el mismo valor.
  • Se considera que la pseudoetiqueta especial //conditions:default coincide si no hay otra condición que coincida. Si se omite esta condición, debe coincidir alguna otra regla para evitar un error.
  • select se puede incorporar dentro de una asignación de atributos más grande. Por lo tanto, srcs = ["common.sh"] + select({ ":conditionA": ["myrule_a.sh"], ...}) y srcs = select({ ":conditionA": ["a.sh"]}) + select({ ":conditionB": ["b.sh"]}) son expresiones válidas.
  • select funciona con la mayoría de los atributos, pero no con todos. Los atributos incompatibles se marcan como nonconfigurable en su documentación.

    subpaquetes

    subpackages(include, exclude=[], allow_empty=True)

    subpackages() es una función auxiliar, similar a glob(), que enumera subpaquetes en lugar de archivos y directorios. Usa los mismos patrones de ruta de acceso que glob() y puede coincidir con cualquier subpaquete que sea un descendiente directo del archivo BUILD que se está cargando. Consulta glob para obtener una explicación detallada y ejemplos de patrones de inclusión y exclusión.

    La lista resultante de subpaquetes que se muestra está ordenada y contiene rutas de acceso relativas al paquete de carga actual que coinciden con los patrones dados en include y no con los de exclude.

    Ejemplo

    En el siguiente ejemplo, se enumeran todos los subpaquetes directos del paquete foo/BUILD

    # The following BUILD files exist:
    # foo/BUILD
    # foo/bar/baz/BUILD
    # foo/bar/but/bad/BUILD
    # foo/sub/BUILD
    # foo/sub/deeper/BUILD
    #
    # In foo/BUILD a call to
    subs1 = subpackages(include = ["**"])
    
    # results in subs1 == ["sub", "bar/baz", "bar/but/bad"]
    #
    # 'sub/deeper' is not included because it is a subpackage of 'foo/sub' not of
    # 'foo'
    
    subs2 = subpackages(include = ["bar/*"])
    # results in subs2 = ["bar/baz"]
    #
    # Since 'bar' is not a subpackage itself, this looks for any subpackages under
    # all first level subdirectories of 'bar'.
    
    subs3 = subpackages(include = ["bar/**"])
    # results in subs3 = ["bar/baz", "bar/but/bad"]
    #
    # Since bar is not a subpackage itself, this looks for any subpackages which are
    # (1) under all subdirectories of 'bar' which can be at any level, (2) not a
    # subpackage of another subpackages.
    
    subs4 = subpackages(include = ["sub"])
    subs5 = subpackages(include = ["sub/*"])
    subs6 = subpackages(include = ["sub/**"])
    # results in subs4 and subs6 being ["sub"]
    # results in subs5 = [].
    #
    # In subs4, expression "sub" checks whether 'foo/sub' is a package (i.e. is a
    # subpackage of 'foo').
    # In subs5, "sub/*" looks for subpackages under directory 'foo/sub'. Since
    # 'foo/sub' is already a subpackage itself, the subdirectories will not be
    # traversed anymore.
    # In subs6, 'foo/sub' is a subpackage itself and matches pattern "sub/**", so it
    # is returned. But the subdirectories of 'foo/sub' will not be traversed
    # anymore.
    

    En general, se prefiere que, en lugar de llamar a esta función directamente, los usuarios usen el módulo "subpackages" de skylib.