Repositorios, espacios de trabajo, paquetes y destinos

Informar un problema Ver fuente Noche /}1}

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

Repositorios

Los archivos fuente que se usan en una compilación de Bazel se organizan en repositorios (a menudo, acortados como repos). Un repositorio es un árbol de directorios con un archivo de marcador de límite en la raíz. Este tipo de archivo puede ser MODULE.bazel, REPO.bazel o, en contextos heredados, WORKSPACE o WORKSPACE.bazel.

El repositorio en el que se ejecuta el comando de Bazel actual se denomina repositorio principal. Otros repositorios (externos) se definen mediante reglas de repositorio. Consulta la descripción general de las dependencias externas para obtener más información.

Espacio de trabajo

Un lugar de trabajo es el entorno que comparten todos los comandos de Bazel que se ejecutan desde el mismo repositorio principal. Abarca el repositorio principal y el conjunto de repositorios externos definidos.

Ten en cuenta que, históricamente, los conceptos de "repositorio" y "lugar de trabajo" se combinaron. El término "espacio de trabajo" a menudo se usa para referirse al repositorio principal 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. 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, más todos los subdirectorios debajo de él, excepto aquellos que contienen un archivo BUILD. Según esta definición, ningún archivo ni 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, sino 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. Por lo general, los archivos fuente se escriben con el esfuerzo de las personas y se registran en el repositorio. Los archivos generados, a veces llamados archivos derivados o archivos de salida, no se registran, pero se generan a partir de archivos fuente.

El segundo tipo de objetivo se declara con una regla. Cada instancia de 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 resultados de otras reglas.

Si la entrada a una regla es un archivo de origen o un archivo generado, en la mayoría de los casos, es irrelevante; lo que importa solo es el contenido de ese archivo. Esto facilita el reemplazo de un archivo fuente complejo por un archivo generado producido por una regla, como sucede cuando la carga de mantener un archivo altamente estructurado de forma manual 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 esas relaciones suele ser bastante complejo y depende del lenguaje o de reglas, pero de manera intuitiva es simple: una regla A de la biblioteca C++ podría tener otra regla B de la biblioteca C++ para una entrada. El efecto de esta dependencia es que los archivos de encabezado de B están 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 misma; no es posible generar archivos en otro paquete. Sin embargo, no es inusual que las entradas de una regla provengan de otro paquete.

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 para hacer referencia a ellos son a partir del atributo visibility de las reglas o del atributo default_visibility de la función package; no generan ni consumen archivos. Para obtener más información, consulta la documentación de package_group.

Etiquetas