Una etiqueta es un identificador de un objetivo. Una etiqueta típica en su versión canónica completa formulario se ve así:
@@myrepo//my/app/main:app_binary
La primera parte de la etiqueta es el nombre del repositorio, @@myrepo
. El doble @
la sintaxis significa que se trata de un repositorio canónico
name, que es único dentro de
espacio de trabajo. Las etiquetas con nombres de repo canónicos identifican de forma inequívoca un destino.
sin importar en qué contexto aparezcan.
A menudo, el nombre del repo canónico es una cadena arcana que se parece a
@@rules_java++toolchains+local_jdk
Lo que se ve con mayor frecuencia
etiquetas con un nombre aparente de repositorio
que se ve así:
@myrepo//my/app/main:app_binary
La única diferencia es que el nombre del repositorio tiene el prefijo uno @
en lugar de dos.
Hace referencia a un repositorio con el nombre aparente myrepo
, que podría ser diferente.
según el contexto en el que aparece esta etiqueta.
En el caso típico en que una etiqueta hace referencia al mismo repositorio desde el cual
cuando se usa, se puede omitir el nombre del repositorio. Dentro de @@myrepo
, la primera
la etiqueta suele escribirse como
//my/app/main:app_binary
La segunda parte de la etiqueta es el nombre del paquete no calificado.
my/app/main
, la ruta de acceso al paquete
en relación con la raíz del repositorio. Juntos, el nombre del repositorio y el
el nombre del paquete no calificado desde el nombre del paquete completamente calificado
@@myrepo//my/app/main
Cuando la etiqueta se refiere al mismo
el paquete en el que se usa, el nombre del paquete (y, opcionalmente, los dos puntos).
puede omitirse. Entonces, dentro de @@myrepo//my/app/main
,
esta etiqueta se puede escribir de cualquiera de las siguientes maneras:
app_binary
:app_binary
Por regla general, se omiten los dos puntos en los archivos, pero se retendrá para las reglas, pero que de otro modo no sea significativo.
La parte de la etiqueta después de los dos puntos, app_binary
es el objetivo no calificado
de la fuente de datos. Cuando coincide con el último componente de la ruta del paquete, este y el
dos puntos, puede omitirse. Por lo tanto, estas dos etiquetas son equivalentes:
//my/app/lib
//my/app/lib:lib
El nombre de un archivo de destino en un subdirectorio del paquete es la ruta de acceso del archivo.
en relación con la raíz del paquete (el directorio que contiene el archivo BUILD
). Entonces:
este archivo se encuentra en el subdirectorio my/app/main/testdata
del repositorio:
//my/app/main:testdata/input.txt
Las cadenas como //my/app
y @@some_repo//my/app
tienen dos significados dependiendo de
el contexto en el que se usan: cuando Bazel espera una etiqueta, significan
//my/app:app
y @@some_repo//my/app:app
, respectivamente. Pero, cuando Bazel
espera un paquete (p.ej., en las especificaciones package_group
), hacen referencia al
paquete que contiene esa etiqueta.
Un error común en los archivos BUILD
es usar //my/app
para hacer referencia a un paquete.
a todos los destinos de un paquete, pero no lo hace. Recuerda que es
equivalente a //my/app:app
, por lo que nombra el destino app
en el my/app
del repositorio actual.
Sin embargo, se recomienda el uso de //my/app
para hacer referencia a un paquete en las
especificación de una package_group
o en archivos .bzl
, porque
comunica que el nombre del paquete es absoluto y tiene permisos de administrador en el nivel superior
de configuración del espacio de trabajo.
Las etiquetas relativas no se pueden usar para hacer referencia a objetivos en otros paquetes. el
En este caso, el identificador del repositorio y el nombre del paquete siempre deben especificarse.
Por ejemplo, si el árbol de fuentes contiene el paquete my/app
y el
paquete my/app/testdata
(cada uno de estos dos directorios tiene su propio
BUILD
), el último paquete contiene un archivo llamado testdepot.zip
. Aquí
hay dos formas (una incorrecta y una correcta) de referirse a este archivo dentro de
//my/app:BUILD
Incorrecto: testdata
es un paquete diferente, por lo que no puedes usar una ruta de acceso relativa.
testdata/testdepot.zip
Correcto: Consulta testdata
con su ruta completa
//my/app/testdata:testdepot.zip
Las etiquetas que comienzan con @@//
son referencias a la clave principal
de código abierto, que seguirá funcionando incluso desde repositorios externos.
Por lo tanto, @@//a/b/c
es diferente de
//a/b/c
cuando se hace referencia desde un repositorio externo.
El primero hace referencia al repositorio principal, mientras que el segundo
Busca //a/b/c
en el repositorio externo.
Esto resulta especialmente relevante cuando se escriben reglas en el archivo
repositorio que se refiera a destinos en el repositorio principal y será
usarse en repositorios externos.
Para obtener información sobre las diferentes formas en que puedes hacer referencia a los objetivos, consulta patrones del objetivo.
Especificación léxica de una etiqueta
La sintaxis de la etiqueta desalienta el uso de metacaracteres que tienen un significado especial para las etiquetas shell. Esto ayuda a evitar problemas de citas involuntarios y facilita construir herramientas y scripts que manipulen las etiquetas, como el Lenguaje de consulta de Bazel.
A continuación, se incluyen los detalles precisos de los nombres de destinos permitidos.
Nombres de destino: package-name:target-name
target-name
es el nombre del destino dentro del paquete. El nombre de una regla
Es el valor del atributo name
en la declaración de la regla en un elemento BUILD
.
file; el nombre de un archivo es su nombre de ruta en relación con el directorio que contiene
el archivo BUILD
.
Los nombres de destino deben estar compuestos en su totalidad por caracteres extraídos del conjunto a
-z
,
A
–Z
, 0
–9
y los símbolos de puntuación !%-@^_"#$&'()*-+,;<=>?[]{|}~/.
.
Los nombres de archivo deben ser nombres de ruta de acceso relativas en su forma normal, lo que significa que deben
ni comienzan ni terminan con una barra (por ejemplo, /foo
y foo/
son
(prohibido) ni contener varias barras consecutivas como separadores de ruta
(por ejemplo, foo//bar
). Del mismo modo, las referencias de nivel superior (..
) y
No están permitidas las referencias del directorio actual (./
).
Incorrecto: No uses ..
para hacer referencia a archivos en otros paquetes.
Correcto: Uso
//package-name:filename
Si bien es común usar /
en el nombre de un archivo de destino, evita usar
/
en los nombres de las reglas. Especialmente cuando la forma abreviada de una etiqueta
usar, puede confundir al lector. La etiqueta //foo/bar/wiz
siempre es una abreviatura
para //foo/bar/wiz:wiz
, incluso si no existe tal paquete foo/bar/wiz
; it
nunca hace referencia a //foo:bar/wiz
, aunque ese destino exista.
Sin embargo, hay algunas situaciones en las que el uso de una barra resulta conveniente o incluso necesarias. Por ejemplo, el nombre de ciertas reglas debe coincidir su archivo fuente principal, que puede estar en un subdirectorio del paquete.
Nombres de paquetes: //package-name:target-name
El nombre de un paquete es el nombre del directorio que contiene su archivo BUILD
.
en relación con el directorio de nivel superior
del repositorio que lo contiene.
Por ejemplo: my/app
.
En un nivel técnico, Bazel aplica de manera forzosa lo siguiente:
- Los caracteres permitidos en los nombres de paquetes son las letras minúsculas
a
az
, las letras mayúsculasA
aZ
, los dígitos0
a9
, el caracteres! \"#$%&'()*+,-.;<=>?@[]^_`{|}
(sí, hay un carácter de espacio) y, por supuesto, barra diagonal/
(ya que es el directorio separador). - Los nombres de paquetes no pueden comenzar ni terminar con el carácter de barra diagonal
/
. - Los nombres de paquetes no pueden contener la subcadena
//
. Esto no haría ¿cuál sería la ruta de acceso al directorio correspondiente? - Los nombres de paquetes no pueden contener la substring
/./
,/../
ni/.../
, etcétera. Esta aplicación se realiza para evitar confusiones cuando se traduce entre de paquete y de directorio físico, dado el significado semántico de la en las cadenas de la ruta de acceso.
En un nivel práctico,
- Para un lenguaje con una estructura de directorio importante para su módulo (por ejemplo, Java), es importante elegir nombres de directorios que sean identificadores válidos en el idioma. Por ejemplo, no empieces con una letra dígito y evita los caracteres especiales, en especial los guiones bajos y los guiones.
- Aunque Bazel admite destinos en el paquete raíz del espacio de trabajo (por ejemplo,
//:foo
), es mejor dejar ese paquete vacío para que todos los paquetes significativos tienen nombres descriptivos.
Reglas
Una regla especifica la relación entre las entradas y salidas, y los pasos para compilar los resultados. Las reglas pueden ser una de muchas reglas similares (a veces denominadas clase de regla), que producen compilaciones de ejecutables y bibliotecas, prueba ejecutables y otros resultados, como se describe en la Enciclopedia de compilación.
Los archivos BUILD
declaran destinos invocando reglas.
En el siguiente ejemplo, vemos la declaración del my_app
de destino.
con la regla cc_binary
.
cc_binary(
name = "my_app",
srcs = ["my_app.cc"],
deps = [
"//absl/base",
"//absl/strings",
],
)
Cada invocación de regla tiene un atributo name
(que debe ser un
target name), que declara un destino dentro del paquete
del archivo BUILD
.
Cada regla tiene un conjunto de atributos. los atributos aplicables a una instancia y la importancia y la semántica de cada atributo son una función de el tipo de la regla; consulta la Enciclopedia de compilación para ver de reglas y sus atributos correspondientes. Cada atributo tiene un nombre un tipo. Algunos de los tipos comunes que puede tener un atributo son números enteros, etiquetas y listas. de etiquetas, cadena, lista de cadenas, etiqueta de salida, lista de etiquetas de salida. No todos los atributos deben especificarse en cada regla. Así, los atributos forman un diccionario desde claves (nombres) hasta valores opcionales escritos.
El atributo srcs
presente en muchas reglas tiene el tipo "lista de etiquetas". es
valor, si está presente, es una lista de etiquetas, cada una de las cuales es el nombre de un objetivo que es
una entrada a esta regla.
En algunos casos, el nombre del tipo de regla es un tanto arbitrario interesantes son los nombres de los archivos que genera la regla, y esto es cierto de genrules. Para obtener más información, consulta Reglas generales: genrule.
En otros casos, el nombre es significativo. Para las reglas *_binary
y *_test
,
por ejemplo, el nombre de la regla determina el nombre del ejecutable que produjo
la compilación.
Este grafo acíclico dirigido sobre los objetivos se denomina grafo de destino. gráfico de dependencias de compilación y es el dominio sobre el cual Funciona la Herramienta de consultas de Bazel.
Objetivos | Archivos de COMPILACIÓN |