Lugares de trabajo, paquetes y destinos

Informar un problema Ver fuente Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Bazel compila software a partir de código fuente organizado en un árbol de directorios llamado Workspace. Los archivos de origen en el espacio de trabajo se organizan en una jerarquía anidada de paquetes, en los que cada paquete es un directorio que contiene un conjunto de archivos fuente y un archivo BUILD. El archivo BUILD especifica qué resultados de software se pueden compilar a partir de la fuente.

Workspace

Un lugar de trabajo es un árbol de directorios en tu sistema de archivos que contiene los archivos fuente del software que deseas compilar. Cada lugar de trabajo tiene un archivo de texto llamado WORKSPACE, que puede estar vacío o contener referencias a dependencias externas necesarias para compilar los resultados.

Los directorios que contienen un archivo llamado WORKSPACE se consideran la raíz de un espacio de trabajo. Por lo tanto, Bazel ignora los árboles de directorios en un espacio de trabajo con permisos de administrador en un subdirectorio que contiene un archivo WORKSPACE, ya que forman otro espacio de trabajo.

Bazel también admite el archivo WORKSPACE.bazel como alias del archivo WORKSPACE. Si ambos archivos existen, se usará WORKSPACE.bazel.

Repositorios

El código se organiza en repositorios. El directorio que contiene el archivo WORKSPACE es la raíz del repositorio principal, también llamada @. Otros repositorios (externos) se definen en el archivo WORKSPACE con reglas de lugar de trabajo o se generan a partir de módulos y extensiones en el sistema Bzlmod. Consulta los recursos Descripción general de las dependencias para obtener más información.

Las reglas del espacio de trabajo agrupadas con Bazel se documentan en la sección Espacio de trabajo Reglas en Build Enciclopedia y la documentación sobre elementos incorporados Reglas del repositorio de Starlark.

Como los repositorios externos son repositorios, a menudo también contienen un archivo WORKSPACE. Sin embargo, Bazel ignora estos archivos WORKSPACE adicionales. En particular, los repositorios de los que se depende de forma transitiva no se añaden automáticamente.

Paquetes

La unidad principal de organización de código en un repositorio es el paquete. Un paquete es una colección de archivos relacionados y una especificación de cómo se pueden usar para producir artefactos de salida.

Un paquete se define como un directorio que contiene un archivo BUILD llamado BUILD o BUILD.bazel. Un paquete incluye todos los archivos de su directorio, además de todos los subdirectorios debajo de él, excepto aquellos que contienen un archivo BUILD. A partir de esta definición, ningún archivo o directorio puede ser parte de dos paquetes diferentes.

Por ejemplo, en el siguiente árbol de directorios, hay dos paquetes, my/app, y el subpaquete my/app/tests. Ten en cuenta que my/app/data no es un paquete, un directorio que pertenece al paquete my/app.

src/my/app/BUILD
src/my/app/app.cc
src/my/app/data/input.txt
src/my/app/tests/BUILD
src/my/app/tests/test.cc

Destinos

Un paquete es un contenedor de destinos, que se definen en el archivo BUILD del paquete. La mayoría de los destinos son uno de los dos tipos principales: archivos y reglas.

Los archivos se dividen aún más en dos tipos. En general, los archivos de origen los escribe los esfuerzos de las personas y se registraron en el repositorio. Los archivos generados, a veces llamados archivos derivados o de salida, no se registran, sino que se generan a partir de archivos de origen.

El segundo tipo de objetivo se declara con una regla. Cada instancia de la regla especifica la relación entre un conjunto de archivos de entrada y uno de salida. Las entradas de una regla pueden ser archivos de origen, pero también pueden ser los resultados de otras reglas.

Si la entrada a una regla es un archivo de origen o un archivo generado está en la mayoría casos irrelevantes; lo que importa es solo el contenido de ese archivo. Este hecho facilita reemplazar un archivo fuente complejo por un archivo generado por una regla, como sucede cuando la carga de mantener manualmente un archivo altamente estructurado se vuelve demasiado agotadora y alguien escribe un programa para derivarlo. No se requiere ningún cambio para los consumidores de ese archivo. Por el contrario, un archivo generado puede reemplazarse fácilmente por un archivo fuente con solo cambios locales.

Las entradas a una regla también pueden incluir otras reglas. El significado preciso de estas son bastante complejas y dependen del idioma o de las reglas, pero intuitivamente es simple: una regla A de la biblioteca C++ podría tener otra biblioteca C++ regla B para una entrada. El efecto de esta dependencia es que los archivos de encabezado de B disponibles para A durante la compilación, los símbolos de B están disponibles para A durante la vinculación, y los datos del tiempo de ejecución de B están disponibles para A durante la ejecución.

Una invariante de todas las reglas es que los archivos que genera una regla siempre pertenecen al mismo paquete que la regla en sí. No es posible generar archivos en otro paquete. No es raro que las entradas de una regla provengan de otra de imágenes, sin embargo.

Los grupos de paquetes son conjuntos de paquetes cuyo propósito es limitar la accesibilidad de ciertas reglas. Los grupos de paquetes se definen con la función package_group. Tienen tres propiedades: la lista de paquetes que contienen, su nombre y otros grupos de paquetes que incluyen. Las únicas formas permitidas de hacer referencia a ellos son desde el atributo visibility de las reglas o desde el atributo default_visibility de la función package. No generan ni consumen archivos. Para ver más consulta la package_group documentación.

Etiquetas