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 los siguientes:
- Usar dependencias detalladas para permitir 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. Como dice la página man de lint: "Se presentará una recompensa especial a la primera persona por producir un programa real que no produzca errores con una revisió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.
En esta página, se utilizan los niveles de requisitos descritos en esta RFC.
Ejecuta compilaciones y pruebas
Un proyecto siempre debe poder ejecutar bazel build //... y bazel test //... de forma correcta en su rama estable. Los objetivos que son necesarios, pero que no se compilan en ciertas circunstancias (como cuando se requieren marcas de compilación específicas, no se compila en una plataforma determinada o se requieren contratos de licencia) se deben etiquetar de la manera más específica posible (por ejemplo, “requires-osx”). Este etiquetado permite filtrar los destinos a un nivel más detallado que la etiqueta “manual” y 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:
- Declara los repositorios 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 compilarse a partir del código 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 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 las versiones, no la incluyas 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 la 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 apuntar ambos destinos a una biblioteca guava, entonces los archivos BUILD son engañosos.
Usa el archivo .bazelrc
Para obtener opciones específicas del proyecto, usa el archivo de configuración tu workspace/.bazelrc (consulta formato 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 contiene 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 sea la estructura, es más probable que se creen dependencias circulares de forma involuntaria, que se cree corrupción el alcance de un objetivo y que se deba actualizar una cantidad cada vez mayor de dependencias inversas.