ant+cpptasks vs. scons vs. make

build-process makefile (5)

Estoy investigando scons y solo quiero asegurarme de saber cuáles son las alternativas, antes de invertir una parte de las células cerebrales en algo completamente diferente. He estado utilizando GNU make en el pasado, pero nunca me ha gustado mucho.

Particularmente: ¿por qué no se usa Ant más a menudo en proyectos C / C ++? (dado que hay tareas de hormigas ) Leí algunas publicaciones que dicen que Ant está más orientada hacia Java (obviamente), pero ¿cuál es el inconveniente de hacerlo? ¿Y por qué los scons son mucho mejores que hacer?

Estoy trabajando con un compilador cruzado para los DSP de TI, por lo general hay 20-50 archivos cpp en un proyecto. Parecería que la parte difícil en la administración de la construcción es la verificación automática de dependencias. Todo lo demás es solo mapear listas de archivos junto con conjuntos de opciones de compilador.

Edición: ¿Y por qué la compilación cruzada cambia algo? es un compilador que se ejecuta de la misma manera que se ejecuta gcc, solo que produce archivos de objetos / ejecutables que no se ejecutan en mi PC.

Ant tiene una base de usuarios muy pesada en Java (por razones naturales). El hecho de que Ant pueda ser muy útil en un entorno mucho más amplio es algo que la mayoría de los desarrolladores que no son de Java desconocen. Como resultado, si usa Ant para construir su C / C ++, codifique su propio código más que si usa un sistema con una base de usuarios más grande (CMake o SCons).

Personalmente, estoy muy contento con CMake, principalmente porque es el único sistema de compilación que puede generar proyectos reales de Visual Studio. SCons también puede, pero solo realizan una llamada externa a SCons, mientras que CMake genera proyectos que utilizan el propio motor de compilación de Visual Studio. Esto es muy útil si está trabajando junto con personas que están acostumbradas a Visual Studio.

No estoy seguro de que llamaría "maduro" al soporte de CMake para la compilación cruzada, ya que todavía es bastante joven. Pero la gente de CMake lo toma en serio, por lo que no dudaría en probarlo.

He estado trabajando en un proyecto en los últimos cinco años que hace x86 y armes construye utilizando ant. Ajustamos cpptasks para nuestros propósitos para producir un compilador genérico al que solo pasamos un prefijo a ... como arm-gum-linux-gnueabi- y luego se añade a la herramienta real como g ++ o ar o lo que sea. Sin prefijo significa que obtienes las herramientas de desarrollo de plataformas de desarrollo. Las cadenas de herramientas para la compilación cruzada tienen esos prefijos en sus binarios de herramientas de compilación. Casi toda la razón para ir con Ant en lugar de hacer cualquier cosa fue la capacidad de cpptasks para hacer compilaciones incrementales y el enredo total de cosas que tienen que suceder para mantener la autoconf feliz. Podemos admitir el paradigma de que se puede crear / renombrar / eliminar casi cualquier archivo de origen, particularmente aquellos en una estructura de árbol de carpetas para un conjunto de bibliotecas, y no es necesario que se realicen modificaciones a los archivos de compilación. Un pequeño inconveniente es que al vincular los archivos se actualizan las propiedades de una manera que causará una reconstrucción innecesaria.

He usado Ant + CppTasks en gran medida hace unos años para crear bases de código muy grandes que se integran en el nuevo código Java a través de JNI, y estoy muy satisfecho con el resultado de compilaciones incrementales muy confiables de código C ++, buena flexibilidad (en archivos de compilación, o mediante ajustes al código). PERO, CppTasks es un proyecto sin comunidad y el mantenedor (Curt Arnold) no ha hecho nada con él durante mucho tiempo. Sigue siendo muy bueno y útil, pero tenga en cuenta que muy poca gente sabe o usa CppTasks (la forma en que los compiladores "ofertan" por los archivos me mordían, por ejemplo, cuando necesitaba un compilador específico para archivos C, y el diferente compilador de C ++ los estaba recogiendo en lugar).

La forma en que CppTasks realiza un seguimiento de las opciones de compilación, y escanea dinámicamente las fuentes para las dependencias de encabezados, todo el tiempo y lo suficientemente rápido (hay cierto almacenamiento en caché de las dependencias), significaba que el único sistema con el que he trabajado tenía compilaciones incrementales precisas, algo muy importante Construcción de bases de código muy grandes.

Así que, como he dicho varias veces en las listas de usuarios / desarrolladores de Ant, si tiene muchas cosas de Java y ya tiene una inversión en Ant, y no tiene miedo de sumergirse en el documento y el código de CppTasks, y ahora es necesario crear el código de "pegamento" de JNI y / o las bibliotecas nativas "heredadas" que el código de pegamento expone, es un candidato que vale la pena y las recompensas pueden ser excelentes.

Fácilmente integré <rc> para la dll de Windows para agregar información completa de la versión, por ejemplo, escribiendo una pequeña tarea Ant para formatear el archivo .res correctamente. Funcionó para mí, pero Ant + CppTasks es definitivamente más para el "avanzado" usuario / desarrollador de Ant IMHO.

Espero que esto ayude. --DD

Me gustaría recomendar terp para la construcción de proyectos en C ++ desde ANT. Desarrollamos terp porque ANT es nuestra herramienta de construcción elegida y las Tareas Cpp se estaban haciendo un poco largas y porque queríamos trabajar en un nivel diferente de abstracción. Terp soporta muchos compiladores diferentes y es soportado por nuestra compañía. Sin embargo, para la mayoría de los proyectos no es gratis.

Diseñamos terp principalmente para reconstrucciones completas en lugar de construcciones incrementales con análisis de dependencia. Estamos llegando allí, pero todavía no está allí. El punto álgido para Terp está en las versiones multiplataforma, multiplataforma y compilador múltiple en las que no desea mantener n configuraciones diferentes para todas las combinaciones. En este punto (julio de 2009) está en versión beta pública, pero se lanzará pronto.

Para la compilación cruzada, creo que sus mejores opciones son CMake o Autotools . Especialmente si puede compilar su código para múltiples arquitecturas / plataformas. Normalmente compilo un subconjunto de mi código en la máquina nativa para propósitos de prueba unitaria y todo para la plataforma de destino. CMake maneja esto especialmente bien, ya que le permite especificar dónde viven las bibliotecas compiladas de forma cruzada. Entonces, en lugar de buscar la libpng compilada en / usr / lib, se le puede decir que busque en / opt / arm-eabi-gcc / o donde sea que tenga las bibliotecas de cadenas de herramientas instaladas en su máquina de compilación. Puede crear múltiples directorios de compilación para las diferentes variantes y compilar manualmente cada variante con make, o desencadenar el lote con un make recursivo hecho a mano.

Ant tiene el inconveniente de que es básicamente tan bueno o tan malo como el de vainilla, con la desventaja adicional de que está usando algo que no es particularmente común para C o C ++. Tiene que lidiar con todas sus propias dependencias, tanto las internas, como el archivo C del archivo de cabecera a la biblioteca o el ejecutable, y también las dependencias externas, como la vinculación con bibliotecas de terceros. Además, no creo que las tareas de Ant C se mantengan tanto. Todos los que he visto que usan defensores de Ant for C llaman a GCC con tareas ejecutivas.

SCons es mejor, pero la compilación cruzada no es su punto fuerte. Tampoco es un "sistema de compilación" como CMake o Autotools, es solo una herramienta de compilación. Como se dice en su wiki, es más o menos "Make in Python" . Sin embargo, sí se ha incorporado en el manejo de dependencias, lo que significa que no tiene que rodar el suyo allí con "gcc -MM -MD" o lo que sea, por lo que es una ventaja sobre Make. SCons también es compatible con la detección de bibliotecas de terceros que están instaladas, pero la forma en que normalmente se hace puede agregar mucho a su tiempo de compilación. A diferencia de otros sistemas, SCons ejecuta la etapa de verificación cada vez que lo ejecuta, aunque la mayoría de los resultados se almacenan en caché. SCons también es famoso por sus largos tiempos de compilación, aunque por 50 archivos que no serían un problema. El soporte de compilación cruzada en SCons es inexistente; debe rodar el suyo como se explica en este hilo en la lista de correo . Por lo general, obligas a que la compilación sea como una plataforma Unix y luego reemplaza el nombre del compilador de C. Crear múltiples variantes o separar el directorio de compilación del directorio de origen está lleno de errores, lo que lo hace menos adecuado si cruzas y compilas de forma nativa tu código.

CMake y Autotools tienen los problemas de dependencia resueltos bastante bien, y el soporte de compilación cruzada de autotools está maduro. CMake ha tenido una compilación cruzada desde la versión 2.6.0, que se lanzó en abril de 2008. Obtiene esas funciones de forma gratuita, además de otras como empaquetado y pruebas de unidades en ejecución ("make check" u objetivos similares). La desventaja de estas dos herramientas es que requieren un programa de arranque. En el caso de CMake, debe tener el binario de CMake instalado para crear los archivos de soluciones Makefiles o Visual Studio. En el caso de Autotools, es un poco más complicado porque no todos los que compilan el software necesitarán automake y autoconf instalados, solo aquellos que necesitan cambiar el sistema de compilación (agregar nuevos archivos cuenta como cambiar el sistema de compilación). El bootstrapping de 2 etapas (configure.ac -> configure, configure + Makefile.in -> Makefile) es conceptualmente un poco más complicado de entender.

Para la edición: la compilación cruzada es un dolor de cabeza adicional en los sistemas de compilación debido a que agrega complejidad a la autodetección de programas y bibliotecas. SCons no se ocupa de este problema, lo deja a usted para que lo resuelva. La hormiga tampoco hace nada. Autoconf maneja esto en el caso de autotools, pero es posible que tenga que proporcionar "--with-libfoobar = / some / path" en la línea de comandos cuando configure o tenga un enlace roto cuando intente usar / usr / lib en la fase de enlace. . El enfoque de CMake tiene un poco más de peso con el archivo de la cadena de herramientas, pero significa que no tiene que especificar todas sus herramientas y bibliotecas (CC, CXX, RANLIB, --with-ibfoo =, etc.), ya que están calculadas a partir de una convención estándar. En teoría, puede reutilizar un archivo de herramientas de CMake adecuadamente diseñado en múltiples proyectos para compilarlos de forma cruzada. En la práctica, CMake no está lo suficientemente extendido como para que sea conveniente para su pirata informático promedio, aunque puede ser útil si está creando múltiples proyectos propietarios.