mensaje de tim
Soy un usuario muy frecuente de GNU. Autoherramientas (principalmente autoconfocasionalmente libtool). Estoy trabajando en un proyecto en el que la portabilidad va a ser un punto conflictivo. Sin embargo, el resto del equipo simplemente no se siente cómodo trabajando con m4. Obtuve este en mi bandeja de entrada de no una, sino cuatro personas:
De todos modos, ¿quizás alguien podría recomendar algo basado en Python o PHP? Estoy trabajando en el extremo C de un árbol mucho más grande; Puedo estar seguro de que Python o PHP 5 estarán presentes, ya que son requisitos previos.
Artem
Me arriesgo a recibir un voto negativo, pero debo admitir que, lamentablemente, no existe un sustituto real para las herramientas automáticas. CMake, SCons, bjam son buenos pero, cuando se trata de un trabajo serio… está bastante claro que las herramientas automáticas son superiores, no porque CMake no pueda hacer lo mismo, sino porque es mucho más difícil hacerlo con él. .
Por ejemplo, CMake, la alternativa más popular a las herramientas automáticas, tiene los siguientes inconvenientes:
- Sin soporte de gettext. Esto puede ser un problema real cuando necesita administrar muchas traducciones y código fuente traducido.
- No hay soporte para un objetivo de desinstalación. Es bastante desagradable descubrir que no puede desinstalar el programa que instaló.
- Sin compilación automática de ambas cosas bibliotecas compartidas y estáticas.
- La documentación es muy limitado y malo.
Y así.
Hay muchos otros puntos. Desafortunadamente, no existe un sustituto real de alta calidad para las herramientas automáticas. Por otro lado, si desarrollas en Windows y para Visual Studio, entonces no puede usar herramientas automáticas y debe elegir CMake que proporciona dichas herramientas.
-
Todo lo que dices es verdad!! Si se quedó con Windows/Linux x86/Mac OS X SCons y CHacer se ve más simple que las herramientas automáticas. Pero si llegas a alguna plataforma inusual tienes muchos problemas…
– givekoa
27 de septiembre de 2011 a las 13:43
-
La gente suele pasar por alto la razón por la que Autotools está escrito en m4. Está escrito en m4 para que el script de configuración pueda generarse en cáscara pura para que se pueda apuntar a cualquier plataforma UNIX. CMake, por otro lado, apunta a cualquier cosa que tenga CMake. Ahora, ¿qué es más común? ¿CMake o Bourne Shell? Yo diría que Bourne Shell. Tampoco es culpa de los escritores de Autoconf que Windows no proporcione un shell decente.
– alternativa
28 de febrero de 2012 a las 23:15
-
Considero que esta es la mejor respuesta. Estoy trabajando con herramientas automáticas regularmente y, de hecho, a veces es doloroso. Pero siempre hago las cosas y las herramientas automáticas estándar proporcionan la configuración resultante y Makefile es excepcionalmente útil. De vez en cuando uso cmake y debo admitir que es mucho más difícil de usar (como en la compilación de la fuente) y no hay suficientes recursos en línea para obtener rápidamente las cosas que estoy haciendo con las herramientas automáticas.
– Pavel Simerda
20 sep 2014 a las 19:13
-
Incluso si es más probable que Bourne Shell ya esté instalado, todavía tiene que descargar alguna cosa para obtener un proyecto para construir (como mínimo, las fuentes, pero lo más probable es que varias dependencias). Dado que una gran cantidad de proyectos ahora requieren CMake, es muy probable que CMake ya esté instalado. CMake tiene sus peculiaridades y desventajas, pero no creo que “no se pueda ejecutar directamente desde un shell” sea un buen argumento en contra de CMake. Aún tienes que descargar alguna cosa.
– Alejandro
18 de julio de 2016 a las 8:44
-
@gavenkoa específicamente, cuando desea pasar por alto las diferencias entre Windows y los sistemas unixoid en CMake, descubrí que eso es un problema.
– 0xC0000022L
2 de diciembre de 2020 a las 16:03
He oído cosas buenas sobre CHacer que trata de resolver los mismos problemas. Aquí es el articulo de wikipedia
-
Usándolo durante mucho tiempo y sin problemas importantes.
– Anónimo
1 de marzo de 2009 a las 19:22
-
Sugeriría lo mismo. Me hice esta pregunta hace algún tiempo y llegué a la conclusión de que CMake es la respuesta correcta.
– Juliano
1 de marzo de 2009 a las 19:23
-
Gracias, parece que Cmake hará exactamente lo que necesito. En estos días, incluso si SUSURRO ‘autoconf’, los aldeanos con antorchas y horcas aparecen en mi escritorio: |
– Tim Publicar
3 de marzo de 2009 a las 7:58
greg hewgill
he tenido mucho éxito con SCons. Está construido con Python y los scripts de construcción son en realidad scripts de Python, lo que le da una gran potencia expresiva. Desde el sitio web:
SCons es una herramienta de construcción de software de código abierto, es decir, una herramienta de construcción de próxima generación. Piense en SCons como un sustituto multiplataforma mejorado del clásico
Makeutilidad con funcionalidad integrada similar aautoconf/automakey cachés del compilador comoccache. En resumen, SCons es una forma más fácil, confiable y rápida de crear software.
Hay muchos generadores alternativos de Makefile y sistemas de compilación diferentes:
- CHacer
- scons
- Waf
- Impulsar la construcción (también conocido como BJam, C++)
También disponible, pero no dirigido estrictamente a C/C++:
- prefabricado
- Hormiga (para Java)
- Rastrillo (para rubí)
- (Definitivamente más, simplemente no los conozco a todos…)
Pero después de enumerar todo esto, las herramientas automáticas tienen la gran ventaja de no requerir ninguna otra dependencia para el usuario final. El desarrollador solo genera una secuencia de comandos de configuración una vez y no requiere nada especial por parte del usuario, ya que es una secuencia de comandos de shell. Las herramientas enumeradas anteriormente deben instalarse antes de que alguien pueda construir su fuente e incluso pueden tener dependencias.
Hendry
¿Qué tal simplemente usar Hacer y pkg-config?
Aquí hay un Plantilla de archivo MAKE para empezar
Menos es más gente.
-
Esa plantilla Makefile no admite dependencias automáticas, lo cual es De Verdad bonito.
– alternativa
28 de febrero de 2012 a las 23:19
-
para eso es pkg-config? hg.suckless.org/surf/file/tip/config.mk#l13
– Hendry
29 de febrero de 2012 a las 14:11
-
No es lo que quise decir. Me refiero a dependencias internas generadas a partir del código fuente entre encabezados, como lo hace GCC. No es particularmente difícil de hacer una vez que descubres cómo hacerlo, pero puede ser un poco doloroso.
– alternativa
29 de febrero de 2012 a las 17:17
-
¿Te gustan esas cosas de gcc -MM -MG -MT? github.com/dontcallmedom/widlproc/blob/master/Makefile#L102
– Hendry
1 de marzo de 2012 a las 2:55
-
Sí, exactamente eso. 🙂 Agregar eso a tu plantilla de makefile realmente es +1
– alternativa
1 de marzo de 2012 a las 3:05
citrina
Un reemplazo automático* más – mk-configure. Se pueden encontrar documentos aquí
-
Esa plantilla Makefile no admite dependencias automáticas, lo cual es De Verdad bonito.
– alternativa
28 de febrero de 2012 a las 23:19
-
para eso es pkg-config? hg.suckless.org/surf/file/tip/config.mk#l13
– Hendry
29 de febrero de 2012 a las 14:11
-
No es lo que quise decir. Me refiero a dependencias internas generadas a partir del código fuente entre encabezados, como lo hace GCC. No es particularmente difícil de hacer una vez que descubres cómo hacerlo, pero puede ser un poco doloroso.
– alternativa
29 de febrero de 2012 a las 17:17
-
¿Te gustan esas cosas de gcc -MM -MG -MT? github.com/dontcallmedom/widlproc/blob/master/Makefile#L102
– Hendry
1 de marzo de 2012 a las 2:55
-
Sí, exactamente eso. 🙂 Agregar eso a tu plantilla de makefile realmente es +1
– alternativa
1 de marzo de 2012 a las 3:05
shodanex
He echado un vistazo a CMake, que parece una buena alternativa a menos que esté compilando de forma cruzada. Si estás haciendo una compilación nativa, deberías probarlo.
La familiaridad con m4 es irrelevante. Argumentar en contra de autoconf debido a m4 es como discutir en contra de C porque el compilador usa un lexer generado por lex y los desarrolladores no entienden lex. Al usar las herramientas automáticas, puede ignorar completamente m4 el 98% del tiempo. ¡En el 2% restante, también puedes ignorar m4! Por lo general, si tiene problemas relacionados con m4 es porque está haciendo algo fundamentalmente incorrecto.
– William Pursell
5 de abril de 2012 a las 16:04
@WilliamPursell después de que hayan pasado un par de años desde que pregunté esto, tiendo a estar de acuerdo. Pero el problema persiste: es demasiado fácil caer en un fundamentalmente equivocado camino usándolo. Y, cuando desea un control de compilación realmente granular desde la configuración, finalmente presiona M4. A menos que me perdí algo?
– Tim Publicar
6 de abril de 2012 a las 7:28
@TimPost Tuve que lidiar con un argumento similar hace años. Nadie quería aprender M4 (ni nada si se podía evitar). El proyecto se convirtió en una combinación de scripts de bash y python, además de una horrible aplicación de C++ que principalmente usaba macros de estilo C. Finalmente, después de tener la autoridad para eliminarlo después de 6 meses de que el sistema se volviera arbitrariamente complicado (aplicación C ++ que llama a python y scripts de shell a través de
system(2)), cambié este lío con un script M4 de 200 líneas. Nunca llegaré a aceptar “no queremos aprenderlo” como una excusa válida.– Nube
4 de diciembre de 2017 a las 17:07