En esta página, se asume que estás familiarizado con Bazel y se proporcionan lineamientos y consejos sobre cómo estructurar tus proyectos para aprovechar al máximo las funciones de Bazel.
Los objetivos generales son los siguientes:
- Para usar dependencias detalladas que permitan el paralelismo y la incrementalidad.
- Para mantener las dependencias bien encapsuladas
- Para que el código esté bien estructurado y se pueda probar.
- Crear una configuración de compilación que sea fácil de entender y mantener.
Estos lineamientos no son requisitos: pocos proyectos podrán cumplir con todos ellos. Como dice la página man de lint: "Se presentará una recompensa especial a la primera persona para producir un programa real que no produzca errores en una verificación estricta". Sin embargo, incorporar tantos de estos principios como sea posible debería hacer que un proyecto sea más legible, menos propenso a errores y más rápido de compilar.
Esta página utiliza los niveles de requisitos descritos en este RFC.
Ejecuta compilaciones y pruebas
Un proyecto siempre debe poder ejecutar bazel build //... y
bazel test //... correctamente en su rama estable. Objetivos necesarios
pero no lo hagas en ciertas circunstancias (como cuando se requiera una compilación
marcas, no deben crearse en una plataforma determinada, exigir contratos de licencia) deben
etiquetada de la forma más específica posible (por ejemplo, “requires-osx”). Esta
el etiquetado permite filtrar las orientaciones a un nivel más detallado que el
"manual" y permite que alguien que inspeccione el archivo BUILD entienda
las restricciones de un objetivo.
Y las dependencias de terceros
Puedes declarar dependencias de terceros:
- Declara los repositorios como repositorios remotos en el archivo
MODULE.bazel. - También puedes colocarlos en un directorio llamado
third_party/en el directorio de tu lugar de trabajo.
Según los objetos binarios
Siempre que sea posible, todo se debe compilar desde la fuente. Generalmente, esto significa
que, en lugar de depender de una biblioteca some-library.so, crearías un
BUILD y compila some-library.so a partir de sus fuentes; luego, dependerá de eso
objetivo.
La compilación siempre a partir del código fuente garantiza que una compilación no use una biblioteca que se compiló con marcadores incompatibles o con una arquitectura diferente. También hay algunas funciones, como la cobertura, el análisis estático o el análisis dinámico, que solo funcionan en la fuente.
Control de versiones
Es preferible compilar todo el código desde head siempre que sea posible. Cuando se deben usar versiones, evita incluirlas en el nombre de destino (por ejemplo, //guava, no //guava-20.0). Este nombre facilita la actualización de la biblioteca (solo se debe actualizar un destino). También es más resistente a la dependencia de diamantes
Problemas: si una biblioteca depende de guava-19.0 y la otra depende de guava-20.0,
podrías terminar con una biblioteca
que intenta depender de dos versiones diferentes.
Si creaste un alias engañoso para dirigir ambas instrucciones a una biblioteca guava, los archivos BUILD son engañosos.
Usa el archivo .bazelrc
Para las opciones específicas del proyecto, usa el archivo de configuración de tu workspace/.bazelrc (consulta el formato bazelrc).
Si deseas admitir opciones por usuario para tu proyecto que no deseas verificar en el control de código fuente, incluye la siguiente línea:
try-import %workspace%/user.bazelrc
(o cualquier otro nombre de archivo) en tu archivo workspace/.bazelrc.
y agrega user.bazelrc a tu .gitignore.
Paquetes
Cada directorio que contiene archivos compilables debe ser un paquete. Si un archivo BUILD hace referencia a archivos en subdirectorios (como srcs = ["a/b/C.java"]), es un indicador de que se debe agregar un archivo BUILD a ese subdirectorio. Cuanto más largo
existe esta estructura, es probable que las dependencias circulares sean
se crea involuntariamente, el alcance del objetivo
se verá sigiloso y aumentará la cantidad
de dependencias inversas tendrá que actualizarse.