Alternativas prometedoras para hacer?
He estado utilizando make y makefiles durante muchos años, y aunque el concepto es sólido, la implementación tiene algo que desear.
¿Alguien ha encontrado alguna buena alternativa para hacer que no complique el problema?
echa un vistazo a SCons . Por ejemplo, Doom 3 y Blender hacen uso de él.
Tengo muchos amigos que confían en CMake para el desarrollo multiplataforma:
Es el sistema de compilación utilizado para VTK (entre otras cosas), que es una biblioteca de C++ con enlaces multiplataforma de Python, Tcl y Java. Creo que es probablemente lo menos complicado que encontrarás con tantas capacidades.
Siempre puedes probar el estándar autotools . Los archivos de Automake son bastante fáciles de armar si solo se está ejecutando en Unix y si se mantiene en C/C++. La integración es más complicada, y autotools está lejos de ser el sistema más simple.
Algunos de los proyectos de GNOME han estado migrando a waf .
Se basa en Python, como Scons, pero también es independiente. Por lo tanto, en lugar de requerir que otros desarrolladores tengan instalada su herramienta de compilación favorita, simplemente copie el script de compilación independiente en su proyecto.
doit es una herramienta de python. Se basa en los conceptos de herramientas de construcción pero más genéricos.
- puede definir cómo se actualiza una tarea/regla (no solo para verificar las marcas de tiempo, no se requieren los archivos de destino)
- las dependencias pueden ser calculadas dinámicamente por otras tareas.
- las acciones de la tarea pueden ser funciones de Python o comandos de Shell.
Tenga en cuenta la ninja herramienta de compilación (v1.8.2 Sept 2017) que está influenciada por tup y redo .
El generador de archivos de compilación cmake (por ejemplo, para Unix Makefiles, Visual Studio, XCode, Eclipse CDT, ...) también puede generar ninja desde la versión 2.8.8 (abril de 2012) y, afaik, ninja ahora es incluso la herramienta de construcción predeterminada utilizada por cmake.
Se supone que supera a la herramienta make (mejor seguimiento de dependencias y también está paralelizado).
cmake es una herramienta ya bien establecida. Siempre puede elegir más tarde la herramienta de compilación sin modificar sus archivos de configuración. Por lo tanto, si se desarrolla una mejor compilación en el futuro que será compatible con cmake, puede cambiar a ella de manera conveniente.
Tenga en cuenta que para c/c ++, mejorar el tiempo de compilación a veces es limitado debido a los encabezados incluidos a través del preprocesador (en particular cuando se utilizan bibliotecas de solo encabezado, por ejemplo boost & eigen ) que Esperemos que sea reemplazado por la propuesta de módulos (en una revisión técnica de c ++ 11 o eventualmente en c ++ 1y). Echa un vistazo a este presentación para obtener detalles sobre este problema.
Escribí una herramienta llamada sake que trataba de hacer que la escritura de cosas como makefile sea muy fácil de leer y escribir.
Depende de lo que estés tratando de hacer. Si todo lo que desea son las dependencias de destino de make-style y la invocación de comandos, entonces Make es en realidad una de las mejores herramientas para la tarea. :-) El rastrillo es muy bueno, pero puede ser torpe para algunos casos simples. Ant es, por supuesto, ciudad de verbosidad, pero tiene mejor soporte para la creación de lenguajes similares a Java (incluidos Scala y Groovy). Además, Ant está disponible en todas partes. Esa es la razón principal por la que lo uso. Debido a que funciona de manera consistente en Windows, en realidad es incluso más multiplataforma que Make.
Si desea una administración de dependencias para bibliotecas similares a Java, Maven es la opción canónica, pero a mí personalmente me gusta mucho más Buildr. Es más rápido y mucho más fácil de personalizar (está basado en Rake). Desafortunadamente, todavía no es tan ubicuo como Maven.
Todavía prefiero hacer después de haber considerado un montón de alternativas. Cuando genera automáticamente dependencias a través del compilador o algo así como fastdep, no queda mucho por hacer. En particular, no quiero que mi script de compilación esté vinculado al lenguaje de implementación, y no me gusta escribir cosas en XML cuando hay alternativas más legibles disponibles. Sin embargo, una herramienta que expone un lenguaje de propósito general tiene mérito, pero otro lenguaje interpretado no lo tiene (afaik). ¿Qué es incorrecto con la marca? puede apelar a su punto de vista acerca de alejarse de la marca.
/Alano
El sistema make de Ruby se llama rake: http://rake.rubyforge.org/
Parece bastante prometedor.
Siempre hay Ant: http://ant.Apache.org , que personalmente me parece horrible. Sin embargo, es el estándar de facto para el desarrollo de Java.
No estoy seguro de si está haciendo la pregunta correcta aquí.
¿Buscas una marca simplificada? En cuyo caso, necesita que alguien que esté muy familiarizado con make cree una serie de akefiles (M | m) que simplifiquen su problema.
¿O quieres mirar la tecnología subyacente? ¿Queremos imponer una arquitectura de tipo de diseño por contrato que se integra y se aplica en el diseño del código? O posiblemente, el lenguaje en sí, por ejemplo. Ada y su concepto de especificaciones (interfaces) y cuerpos (implementaciones)?
¿Qué dirección está siguiendo definitivamente afectará los resultados potenciales de tal pregunta?
Básicamente, nuevas formas de construir sistemas solo a partir de aquellos componentes que realmente han cambiado frente a la adopción de nuevas tecnologías que tienen tales mecanismos incorporados por diseño.
Lo siento, no es una respuesta directa. Solo quería intentar y hacer que evalúes qué camino querías seguir hacia abajo.
aclamaciones,
Robar
FlowTracer de RTDA es otra buena opción que he utilizado comercialmente en un entorno a gran escala (decenas de miles de trabajos): http://www.rtda.com/flowtracer-design-flow-infrastructure-software
Tiene una GUI que muestra el gráfico de dependencia con cuadros codificados por colores para trabajos y óvalos para archivos. Cuando la cantidad de trabajos y archivos aumenta, una herramienta basada en GUI como FlowTracer es bastante esencial.
El costo de configuración inicial es más alto que el de Make. Hay una curva de aprendizaje para configurar su primer flujo usándolo. Después de eso, se pone más rápido.