Bazel crea software a partir de código fuente organizado en árboles de directorios llamados
de Cloud Storage. El espacio de trabajo consta de un conjunto definido de repositorios. Fuente
los archivos en repositorios se organizan en una jerarquía anidada de paquetes, en la que
cada paquete es un directorio que contiene un conjunto de archivos de origen relacionados y una
BUILD. El archivo BUILD especifica a partir de qué resultados de software se pueden compilar
de la fuente.
Repositorios
Los archivos fuente usados en una compilación de Bazel se organizan en repositorios (a menudo,
se abrevia como repos). Un repo es un árbol de directorios con un archivo de marcador de límite en
su raíz; un archivo de marcador de límite podría ser MODULE.bazel, REPO.bazel o
en contextos heredados, WORKSPACE o WORKSPACE.bazel.
El repositorio en el que se ejecuta el comando actual de Bazel se denomina principal repo. Los repositorios (externos) se definen a través de reglas de repositorio. consulta recursos externos de las dependencias para obtener más información.
Lugar de trabajo
Un lugar de trabajo es el entorno que comparten todos los comandos de Bazel que se ejecutan desde el mismo repo principal. Abarca el repo principal y el conjunto de todas las definiciones repos.
Históricamente, los conceptos de “repositorio” y “espacio de trabajo” han sido combinadas; el término “espacio de trabajo” se suele usar para referirse a los principales repositorio y, a veces, incluso se usa como sinónimo de "repositorio".
Paquetes
La unidad principal de organización de código en un repositorio es el paquete. R paquete es una colección de archivos relacionados y una especificación de cómo se pueden que se usa para producir artefactos de salida.
Un paquete se define como un directorio que contiene un
Archivo BUILD llamado BUILD o BUILD.bazel. R
incluye todos los archivos en su directorio, más todos los subdirectorios debajo de él,
excepto aquellos que contienen un archivo BUILD. A partir de esta definición, no
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 la interfaz del
Archivo BUILD. 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. Archivos generados, denominados archivos derivados o archivos de salida, no se registran, pero generados a partir de archivos fuente.
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. El Las entradas de una regla pueden ser archivos de origen, pero también pueden ser la salida de otras las reglas de firewall.
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 dato facilita el reemplazo de un archivo fuente complejo con un archivo generado producido por una regla, como cuando la carga de mantener manualmente un archivo estructurado se vuelve demasiado tedioso 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 pueden 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 a el mismo paquete que la regla misma; 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. Ellas
tienen tres propiedades: la lista de paquetes que contienen, su nombre y otras
grupos de paquetes que incluyen. Las únicas formas permitidas para referirse a ellos son desde el
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.