¿Cómo se "refactorizan" los archivos ant build.xml?

Question

Estoy trabajando en un gran sistema C++ construido con ant + cpptasks. Funciona bastante bien, pero el archivo build.xml se está saliendo de control, debido al procedimiento operativo estándar para agregar una nueva biblioteca o un objetivo ejecutable para copiar y pegar las reglas de otra lib/exe (que ya son bastante grandes). Si este fuera el "código correcto", estaría pidiendo a gritos una refactorización, pero al ser un novato de hormiga (más utilizado para hacer o soluciones de VisualStudio) no estoy seguro de cuáles son las opciones.

¿Cuáles son las mejores prácticas de los usuarios de hormigas para detener la explosión de archivos de compilación de hormigas?

Una opción obvia sería producir el build.xml a través de XSLT, definiendo nuestras propias etiquetas para los patrones comúnmente recurrentes. ¿Alguien hace eso, o hay mejores formas?

Answer 1

usted puede estar interesado en:

• <import>
• <macrodef>
• <subant>

Check también este artículo en "ant features for big projects".

Answer 2

Si las reglas son repetitivas, puede factorizarlas en una macro de hormigas usando macrodef y reutilizar esa macro.

Si el tamaño del archivo es inmanejable, entonces quizás pueda dividirlo en archivos más pequeños y tener los principales destinos de llamadas build.xml dentro de esos archivos.

Si no es ninguno de estos, entonces es posible que desee considerar el uso de un sistema de compilación. Aunque no he usado Maven, sé que puede resolver muchos problemas de archivos de construcción grandes e inmanejables.

Answer 3

Me gustaría probar Ant-Ivy- the agile dependency manager. Recientemente hemos comenzado a usarlo para algunos de nuestros sistemas más complejos y funciona como un encanto. La ventaja aquí es que no obtienes los gastos generales y de transición para maven (usa objetivos ant, por lo que funcionará con tu configuración actual). Here is a comparison entre los dos.

Answer 4

En general, si su archivo de compilación es grande y complejo, esta es una clara indicación de que la forma en que se muestra el código, en términos de carpetas y paquetes, es complejo y demasiado complicado. Encuentro que un guión de hormiga complejo es un olor claro a una base de código mal diseñada.

Para solucionar esto, piense en cómo se presenta su código. ¿Cuántos proyectos tienes? ¿Saben esos proyectos cómo construirse a sí mismos con un script maestro de compilación que sabe cómo agrupar los proyectos/aplicaciones/componentes individuales en un todo más grande?

Cuando está refabricando el código, está buscando formas o dividiendo las cosas para que sean más fáciles de entender: métodos más pequeños, clases más pequeñas, métodos y clases que hacen una cosa. También debe aplicar estos mismos principios a su código base.

Crea componentes más pequeños que son funcionalmente cohesivos y están muy poco desacoplados del resto del código. Use un script de construcción para construir ese componente en una biblioteca. Haz esto con el resto de tu código. Ahora crea una secuencia de comandos de compilación maestra que sepa cómo agrupar todas tus bibliotecas y compilarlas en tu aplicación. Si tiene varias aplicaciones, cree un script de compilación para cada aplicación y otro maestro que sepa cómo agrupar las aplicaciones en distributables.

Debería ser capaz de ver y entender el diseño y la estructura de su código base con solo mirar sus scripts de compilación. Si they/it no es limpio y comprensible, tampoco lo es su código fuente.

Answer 5

Utilice archivos Antlib. Es una forma muy limpia para

1. copia Quitar código/pegado
2. definir valores por defecto

Si desea ver un ejemplo, se puede echar un vistazo a algunos de los build script estoy escribiendo para mis proyectos de sandbox.