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:
- 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.
Estas pautas no son requisitos: pocos proyectos podrán cumplir con todos ellos. Como dice la página man de lint, “Se le presentará una recompensa especial a la primera persona que cree un programa real que no genere errores con 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.
En esta página, se usan los niveles de requisitos que se describen en esta RFC.
Ejecuta compilaciones y pruebas
Un proyecto siempre debe poder ejecutar bazel build //... y
bazel test //... se realizó correctamente en su rama estable. Los destinos que son necesarios, pero que no se compilan en determinadas circunstancias (como requerir marcas de compilación específicas, no compilarse en una plataforma determinada o requerir contratos de licencia) deben etiquetarse de la forma 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 permite que alguien que inspeccione el archivo BUILD comprenda cuáles son las restricciones de un destino.
Y las dependencias de terceros
Puedes declarar dependencias de terceros de las siguientes maneras:
- 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.
Siempre compilar 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
Prefiere compilar todo el código desde la parte superior siempre que sea posible. Cuando las versiones
usado, 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 una
el destino debe actualizarse). También es más resistente a los problemas de dependencia de diamante: si una biblioteca depende de guava-19.0 y 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 apuntar ambos objetivos a una biblioteca guava,
entonces 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 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 tiempo exista esta estructura, es más probable que se creen dependencias circulares por error, que se extienda el alcance de un destino y que se deba actualizar una cantidad cada vez mayor de dependencias inversas.