En esta página, se supone 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:
- Usar dependencias detalladas para permitir el paralelismo y la incrementalidad
- Para mantener las dependencias bien encapsuladas
- Hacer que el código esté bien estructurado y se pueda probar
- Crear una configuración de compilación que sea fácil de comprender y mantener
Estos lineamientos no son requisitos: pocos proyectos podrán cumplir con todos. Como dice la página man de lint: "Se entregará una recompensa especial a la primera persona que produzca un programa real que no produzca errores con una verificación estricta". Sin embargo, incorporar la mayor cantidad posible de estos principios debería hacer que un proyecto sea más legible, menos propenso a errores y más rápido de compilar.
En esta página, se usan los niveles de requisitos descritos en esta RFC.
Ejecuta compilaciones y pruebas
Un proyecto siempre debe poder ejecutar bazel build //... y bazel test //... de manera correcta en su rama estable. Los destinos que son necesarios, pero que no se compilan en ciertas circunstancias (como que requieren marcas de compilación específicas, no se compilan en una plataforma determinada o requieren contratos de licencia) deben etiquetarse de la manera más específica posible (por ejemplo, "requires-osx"). Este etiquetado permite filtrar los objetivos en un nivel más detallado que la etiqueta "manual" y permite que alguien que inspeccione el archivo BUILD para comprender cuáles son las restricciones de un destino.
Y las dependencias de terceros
Puedes declarar dependencias de terceros:
- Declaralos como repositorios remotos en el archivo
WORKSPACE. - También puedes colocarlos en un directorio llamado
third_party/en el directorio de tu lugar de trabajo.
Según los objetos binarios
Todo debe basarse en la fuente siempre que sea posible. Por lo general, esto significa que, en lugar de depender de una biblioteca some-library.so, deberías crear un archivo BUILD y compilar some-library.so a partir de sus fuentes y, luego, depender de ese destino.
La compilación siempre a partir del código fuente garantiza que una compilación no use una biblioteca que se compiló con marcas incompatibles o una arquitectura diferente. También existen 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
Prefiere compilar todo el código desde el encabezado, siempre que sea posible. Cuando se deban usar versiones, evita incluir la versión en el nombre del 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 los problemas de dependencia de diamantes: si una biblioteca depende de guava-19.0 y otra depende de guava-20.0, podrías terminar con una biblioteca que intente depender de dos versiones diferentes.
Si creaste un alias engañoso para dirigir ambos destinos a una biblioteca guava, los archivos BUILD son engañosos.
Usa el archivo .bazelrc
Para ver las opciones específicas del proyecto, usa el archivo de configuración de tu
workspace/.bazelrc (consulta el formato de bazelrc).
Si deseas admitir opciones por usuario para tu proyecto que no quieres registrar 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 workspace/.bazelrc
y agrega user.bazelrc a tu .gitignore.
Paquetes
Cada directorio que contenga archivos compilables debe ser un paquete. Si un archivo BUILD hace referencia a archivos en subdirectorios (como srcs = ["a/b/C.java"]), es una señal de que se debe agregar un archivo BUILD a ese subdirectorio. Cuanto más larga exista esta estructura, más probable es que se creen dependencias circulares de forma involuntaria, se extienda el alcance de un destino y se deba actualizar un número creciente de dependencias inversas.