Funciones

Informar un problema Ver fuente

Contenido

• paquete
• package_group
• exports_files
• globo terráqueo
• seleccionar
• subpaquetes

paquete

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

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

Se debe llamar a la función package() justo después de todas las sentencias 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 [] La visibilidad predeterminada de las reglas en este paquete. Cada regla de este paquete tiene la visibilidad especificada en este atributo, a menos que se especifique lo contrario en el atributo visibility de la regla. Para obtener información detallada sobre la sintaxis de este atributo, consulta la documentación sobre la visibilidad. 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 "" Configura el mensaje deprecation predeterminado para todas las reglas del 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 objetivos 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 que se indique lo contrario Configura la propiedad testonly predeterminada para todas las reglas de este paquete. En los paquetes en javatests, el valor predeterminado es True.
features	Enumerar strings; el valor predeterminado es [] Configura varias marcas que afectan la semántica de este archivo BUILD. Esta función es utilizada principalmente por las personas que trabajan en el sistema de compilación para etiquetar paquetes que necesitan algún tipo de manejo especial. No lo uses a menos que alguien que trabaje en el sistema de compilación lo solicite explícitamente.

Ejemplos

La siguiente declaración declara que las reglas de este paquete son visibles solo 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 ese conjunto. Se puede hacer referencia a la etiqueta en los atributos visibility.

Los grupos de paquetes se usan principalmente para el control de visibilidad. Se puede hacer referencia a un destino visible públicamente desde cada paquete en el árbol de fuentes. Solo se puede hacer referencia a un destino visible de forma privada dentro de su propio paquete (no en subpaquetes). Entre estos extremos, un objetivo 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 visibilidad.

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

Los grupos de paquetes son objetivos técnicos, pero no se crean mediante reglas y no tienen ninguna protección de visibilidad.

Argumentos

Atributo	Descripción
name	Nombre (obligatorio) 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 del paquete puede tener uno de los siguientes formatos: El nombre completo de un paquete, sin su repositorio, y comienza con una doble barra diagonal. Por ejemplo, //foo/bar especifica el paquete que tiene ese nombre y que se encuentra en el mismo repositorio que el grupo de paquetes. Como se muestra más arriba, pero con un /... al final. Por ejemplo, //foo/... especifica el conjunto de //foo y todos sus subpaquetes. //... especifica todos los paquetes en el repositorio actual. Las strings public o private, que especifican, respectivamente, cada paquete o ninguno. (En este formulario, se requiere que se configure la marca --incompatible_package_group_has_public_syntax). Además, los dos primeros tipos de especificaciones de paquetes también pueden tener el prefijo - para indicar que se han negado. 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. (//foo se incluye, mientras que //foo/tests no lo está). Aparte de la visibilidad pública, no hay manera de especificar directamente los paquetes fuera del repositorio actual. Si falta este atributo, es lo mismo que configurarlo como una lista vacía, que también es lo mismo que configurarlo en una lista que solo contenga private. Nota: Antes de Bazel 6.0, la especificación //... tenía el mismo comportamiento heredado de ser igual que public. Este comportamiento se corrige cuando --incompatible_fix_package_group_reporoot_syntax está habilitado, 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 --incompatible_package_group_includes_double_slash está habilitado, 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 referirse a otros grupos de paquetes. Los paquetes de los grupos de paquetes a los que se hace referencia forman parte de este grupo de paquetes. 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 las especificaciones de paquetes negadas, ten en cuenta que el conjunto de paquetes para cada grupo se calcula primero de forma independiente y, luego, los resultados se unen. Esto significa que las especificaciones anuladas en un grupo no tienen efecto en las especificaciones de otro grupo.

Ejemplos

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

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

Las siguientes declaraciones 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 que se exportan a otros paquetes.

El archivo BUILD de un paquete solo puede hacer referencia directamente 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, también los archivos mencionados como entrada para una regla 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 encuentra todos los archivos que coinciden con ciertos patrones de ruta de acceso y muestra una nueva lista mutable y ordenada de sus rutas de acceso. Glob solo busca archivos en su propio paquete y busca solo archivos de origen (no archivos generados ni otros destinos).

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

Las listas include y exclude contienen patrones de ruta de acceso relacionados con el paquete actual. Cada patrón puede constar de uno o más segmentos de ruta. Como es habitual con las rutas de acceso Unix, estos segmentos están separados por /. Los segmentos pueden contener el comodín *: coincide con cualquier substring en el segmento de ruta de acceso (incluso la substring vacía), sin incluir 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 debe declararse como un segmento de ruta independiente.

Ejemplos:

• foo/bar.txt coincide exactamente con el archivo foo/bar.txt de este paquete.
• foo/*.txt coincide con todos los archivos del directorio foo/ si el archivo termina en .txt (a menos que foo/ sea un subpaquete).
• foo/a*.htm* coincide con cada archivo en el directorio foo/ que comienza con a, luego tiene una string arbitraria (podría estar vacía), luego tiene .htm y termina con otra string arbitraria, como foo/axx.htm y foo/a.html o foo/axxx.html
• **/a.txt coincide con cada archivo a.txt en cada subdirectorio de este paquete.
• **/bar/**/*.txt coincide con cada archivo .txt en cada subdirectorio de este paquete si al menos un directorio de la ruta 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 cada archivo en cada subdirectorio de este paquete
• foo**/a.txt es un patrón no válido, porque ** debe permanecer por sí solo como un segmento.

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, de lo contrario, sería la lista vacía.

Existen varias limitaciones y advertencias importantes:

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

2. Si una regla tiene el mismo nombre que un archivo de origen coincidente, la regla “sombra” del archivo.

   Para comprenderlo, recuerda que glob() muestra 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 coincidentes de forma explícita. Si, por ejemplo, glob() genera ["Foo.java", "bar/Baz.java"], pero también hay una regla en el paquete llamada "Foo.java" (lo cual está permitido, aunque Bazel advierte al respecto), 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 encontrar coincidencias con los archivos de los subdirectorios. Además, los nombres de los subdirectorios pueden estar comodines. Sin embargo…

4. Las etiquetas no pueden cruzar el límite del paquete y glob no coincide con los archivos en 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 otro lugar de la ruta 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 había un paquete llamado x/y o si se marcó como borrado mediante 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 de archivo comienza con . coincide completamente con los comodines ** y *. Si quieres hacer coincidir un archivo oculto con un patrón compuesto, el patrón debe comenzar con un .. Por ejemplo, * y .*.txt coincidirán con .foo.txt, pero *.txt no. Los directorios ocultos también coinciden de la misma manera. Los directorios ocultos pueden incluir archivos que no son necesarios como entradas y pueden aumentar la cantidad de archivos globeados innecesariamente y el consumo de memoria. Para excluir los directorios ocultos, agrégalos al argumento de la lista "excluir".
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 = 0) coincide de forma transitiva con todos los archivos y directorios dentro del directorio del paquete actual (pero, por supuesto, no en los directorios de subpaquetes; consulta la nota anterior al respecto).

En general, debes intentar proporcionar una extensión adecuada (p.ej., *.html) en lugar de usar un '*' simple para un patrón glob. El nombre más explícito es autodocumentado y garantiza que no hagas coincidir accidentalmente archivos de copia de seguridad o archivos de guardado automático emacs/vi/....

Cuando escribes reglas de compilación, puedes enumerar los elementos del glob. Esto permite generar reglas individuales para cada entrada, por ejemplo. Consulta la sección del ejemplo de glob expandido a continuación.

Ejemplos de glob

Crea una biblioteca Java compilada a partir de todos los archivos Java de este directorio y de 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 en el directorio testdata, salvo experimental.txt. Ten en cuenta que no se incluirán los archivos en los subdirectorios de los datos de prueba. Si deseas 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 globos terráqueos recursivos

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

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 de todos los subdirectorios, excepto aquellos cuya ruta de acceso incluya un directorio llamado Testing. Este patrón debe evitarse siempre que sea posible, ya que puede reducir la incrementalidad de compilación y, por lo tanto, aumentar los tiempos de compilación.

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

Ejemplos de globo terráqueo expandido

Crea una genrule individual para *_test.cc en el directorio actual que cuente la cantidad de líneas en el 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 se encuentra en el paquete //foo y el paquete contiene tres archivos coincidentes, a_test.cc, b_test.cc y c_test.cc, cuando se ejecute bazel query '//foo:all', se mostrarán 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

select

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 atributo, por lo que su valor depende 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 incorporar diferentes recursos en función de si una regla se compila en modo de "desarrollador" o de "lanzamiento".

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 mediante el reemplazo de su asignación normal de lista de etiquetas por una llamada 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. 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 cada invocación.
• Si varias condiciones coinciden y una es una especialización de las demás, tiene prioridad la especialización. 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 la especialización no está diseñada para crear un orden como se muestra en el ejemplo 2 a continuación.
• Si varias condiciones coinciden 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 en el mismo valor.
• Se considera que la seudoetiqueta especial //conditions:default coincide si no coincide ninguna otra condición. Si se excluye esta condición, alguna otra regla deberá coincidir para evitar un error.
• select se puede incorporar dentro de una asignación de atributo 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 subordinado 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á en orden y contiene rutas relacionadas con el 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/sub/BUILD
  # foo/sub/deeper/BUILD
  #
  # In foo/BUILD a call to
  subs = subpackages(include = ["**"])
  
  # results in subs == ["sub", "bar/baz"]
  #
  # 'sub/deeper' is not included because it is a subpackage of 'foo/sub' not of
  # 'foo'
  

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