2011-04-29 41 views
30

He estado buscando pros & contras de Autotools y CMake. Pero me gustaría conocer las opiniones de personas que han usado una (o ambas) de estas herramientas para proyectos.Autotools vs CMake

Utilicé Autotools básicamente hace un año y sé que uno de los puntos buenos es que se basa en el shell scripting, por lo tanto, no necesita instalarse para ejecutarse. Pero parece que está demasiado orientado a Linux, y no sería posible ejecutar el archivo de configuración en Windows.

Tengo que elegir una herramienta de sistema de compilación para an open source project que deberá compilarse para al menos Linux & Windows. Está escrito en C++, y usa una interfaz gráfica de usuario de Qt, el resto es "genérico".

Gracias por su ayuda.

+1

posible duplicado de [Autotools vs. Cmake vs. Scons] (http://stackoverflow.com/questions/4071880/autotools-vs-cmake-vs-scons) – ptomato

Respuesta

30

No recomendaría autotools para Windows. Use CMake.

¿Por qué? Windows no tiene un sh.exe nativo y la emulación es lenta. También es muy fácil hacer que configury funcione mal. No digo que sea imposible en CMake, pero seguramente CMake abstrae más, así que te preocupas menos. La documentación de CMake puede ser un poco difícil de leer, pero una vez que está configurada, debería estar bien para todas las cadenas de herramientas compatibles con CMake. CMake también integra pruebas, empaquetamiento, etc.

Autotools es lento en Windows, no funciona fácilmente con MSVC, y tiene peculiaridades extrañas con Windows (y otros SO) que son difíciles de depurar y difíciles de corregir. libtool también apesta a Windows, donde a menudo se niega a construir una biblioteca compartida, incluso si crees que debería y podría. Los problemas de reubicación de la cadena de herramientas también prevalecen con libtool, que puede ver los archivos incorrectos en la cadena de herramientas de un usuario. CMake es mucho más fácil en este sentido. Asume cosas normales sobre la plataforma de destino y crea instrucciones genéricas y buenas de compilación.

Además, CMake tiene una salida de color :) y buenos porcentajes de progreso.

PD: Acabo de tener alguna experiencia con CMake y autotools en Windows como usuario. CMake tiende a trabajar, autotools tiende a morder la oreja cuando usted no está buscando, y sonreír a que cuando falla debido a algún error extraño ...

+0

Conclusión agradable jaja: D Hablando de CTest, ¿usted ¿Piensa que es una buena idea usarlo incluso para un proyecto pequeño con pocas pruebas (~ 120)? Realmente no veo muchas ventajas en comparación con un shell de script hecho a sí mismo muy fácil de hacer (lo que significa que solo se probará en una plataforma basada en Unix para el shell). –

+0

@Julio: bueno, CTest garantiza (creo) principalmente la compatibilidad de plataforma. Nadie te obliga a usar otras partes de Cmake. – rubenvb

+0

Muy bien dicho, esta es la razón por la que a menudo uso la frase "todo compila en * nix", porque la mayoría de las cosas tienen un guión de configuración de autoconf pero no un CMakeLists.txt, y luego hay un aumento ... la compilación es una pesadilla inconsistente en Windows :) –

55

Actualizado 19o de de junio de 2017

tengo utilizó autotools antes durante un tiempo considerable.

Actualmente hago un uso intensivo de cmake y meson en el trabajo y para proyectos personales, respectivamente.

algunos consejos personales:

  1. para grandes equipos, se adhieren a CMake si desea hacer uso de los generadores de VS y XCode. Si no los necesitas, consideraría seriamente el mesón.
  2. Elige meson sobre autotools a menos que necesites algo realmente esotérico que soporte autotools y meson no. De lo contrario, en mi humilde opinión, Meson es una opción mucho mejor que autotools ya, y podrá soportar ventanas.

También he intentado scons, waf y tup.

El sistema multiplataforma más completo es CMake, pero el DSL de meson será más fácil de usar para las personas que usan python y otros. Meson también está comenzando a admitir VS (un generador VS2015) y algunos proyectos ya tienen soporte experimental para él, por ejemplo gstreamer. Gstreamer se compila también en ventanas con mesón. Ahora mismo hay un generador VS2015 y VS2017 pero no me he probado los generadores últimamente. A partir de meson 0.37.1 se necesita algo de trabajo, pero están mejorando y la versión actual ya es 0.40.

Meson

Pros:

  • El DSL no se interpone en el camino en absoluto. De hecho, es muy agradable y familiar, basado en python.
  • Soporte de compilación cruzada bien pensado.
  • Todos los objetos están fuertemente tipados: no se pueden hacer errores de sustitución de cadenas fácilmente, ya que los objetos son entidades como 'depencency', 'include directory', etc.
  • Es muy obvio cómo agregar un módulo para uno de tus herramientas
  • La compilación cruzada parece más fácil de usar.
  • Realmente bien pensado. El diseñador y escritor principal de Meson sabe de qué habla muy bien cuando diseña un sistema de compilación.
  • Muy, muy rápido, especialmente en versiones incrementales.
  • La documentación es 10 veces mejor que la que puede encontrar en cmake. Vaya a visitar http://mesonbuild.com y encontrará tutorial, howtos y una buena referencia. No es perfecto, pero es realmente reconocible.

Contras:

  • No es tan madura como CMake, sin embargo, considero que es ya plenamente utilizable para C++.
  • No hay tantos módulos disponibles, sin embargo, gnome, qt y los comunes ya están allí.
  • Generadores de proyectos: parece que el generador VS no funciona tan bien a partir de ahora. Los generadores de proyectos CMake son mucho más maduros.
  • Tiene una dependencia python3 + ninja.

CMAKE

Pros:

  • Genera proyectos para muchos entornos de desarrollo diferentes. Esta es una buena característica muy para equipos.
  • Juega bien con herramientas de Windows, a diferencia de las autotools.
  • estándar maduro, casi de facto.
  • Microsoft está trabajando en la integración de CMake para Visual Studio.

Contras:

  • no se sigue ningún estándar o directrices bien conocido.
  • Sin destino de desinstalación.
  • El DSL es extraño, cuando comienzas a hacer comparaciones y cosas así, y las cuerdas contra lo de la lista o los caracteres de escape, cometerás muchos errores, estoy bastante seguro.
  • Compilación cruzada es una mierda.

Autotools

Pros:

  • sistema más potente para la compilación cruzada, en mi humilde opinión.
  • Los scripts generados no necesitan nada más que make, un shell y, si lo necesita para compilar, un compilador.
  • La línea de comandos es realmente agradable y consistente.
  • Un estándar en el mundo de Unix, muchos documentos.
  • realmente potente de línea de comandos: cambiar los directorios de instalación, desinstalación, binarios de cambio de nombre ...
  • Si se dirige a UNIX, fuentes de envasado con esta herramienta es realmente conveniente.

Contras:

  • no va a jugar bien con las herramientas de Microsoft. Un verdadero espectáculo.
  • La curva de aprendizaje es ... bueno ... Pero en realidad puedo decir que CMake tampoco fue tan fácil.

Sobre la curva de aprendizaje, hay dos muy buenas fuentes para aprender de:

La primera fuente le conseguirá y corriendo más rápido El libro es una discusión más profunda.

Desde Scons, waf y tup, Scons y tup son más como make. Waf se parece más a CMake y a las autotools. Intenté waf en lugar de cmake al principio. Creo que está sobreinyectado en el sentido de que tiene una API OOP completa. Los guiones no parecían cortos en absoluto y para mí era realmente confuso el material del directorio de trabajo y cosas relacionadas. Al final, descubrí que las autotools y CMake son una mejor opción. Mi favorito de estos 3 sistemas de construcción es tup.

Tup

Pros

  • realmente correcto.
  • Increíblemente rápido. Deberías intentarlo para creerlo.
  • El lenguaje de scripts se basa en una idea muy fácil que se puede entender en 10 minutos.

Contras

  • No tiene un marco de configuración con todas las funciones.
  • No pude encontrar la manera de hacer objetivos como doc, ya que generan archivos que desconozco y deben aparecer en la salida antes de generarse, o al menos, esa es mi conclusión por el momento. Esta era una limitación realmente molesta, si es así, ya que no estoy seguro.

En general, lo único que estoy considerando ahora para nuevos proyectos es Cmake and Meson. Cuando tengo la oportunidad, intentaré subir también, pero carece del marco de configuración, lo que significa que hace las cosas más complejas cuando necesitas todas esas cosas. Por otro lado, es realmente rápido.

+1

descripción muy agradable; gracias por el enlace a _Autotools Mythbuster_. Tengo un e-book del libro de Calcote, pero es agradable ver otra perspectiva. gracias – Geremia

+1

¡Gracias por esto! Meson se ve bastante bien, lo único que no me gusta es más que nada una cosa de python (administrar múltiples versiones instaladas). ¿Tiene Meson una manera de construir subproyectos que usan un sistema de compilación diferente? Vi una forma de ejecutar un comando externo, que podría funcionar, pero parece no ser tan elegante. – Ryan

+0

No estoy seguro de que lo haga, pero siempre puede integrar una secuencia de comandos. En realidad, prefiero que el mesón toque manos. El tiempo que pierdes luchando contra el lenguaje de scripting en cmake se guarda en meson, podrías usarlo para integrarlo. Pero recuerdo que wrap meson (esta es la función de subproyectos de meson) admite ahora precompilados y de origen. Para compilar desde el origen, desafortunadamente, necesitas un archivo meson. Para proyectos pequeños es fácil, para grandes proyectos quizás no sea factible rehacer esto todo el tiempo. –