52
Soy un usuario muy frecuente de GNU Autotools (principalmente Autoconf, ocasionalmente Libtool). Estoy trabajando en un proyecto donde la portabilidad va a ser un punto difícil. Sin embargo, el resto del equipo simplemente no se siente cómodo trabajando con m4. Tengo this en mi bandeja de entrada de no uno, sino cuatro personas:Alternativas a Autoconf y Autotools?
De todos modos, tal vez alguien podría recomendar algo o Python basado en 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.
La familiaridad con m4 es irrelevante. Discutir contra el autoconf debido a m4 es como argumentar en contra de C porque el compilador usa un lexer generado por lex y los desarrolladores no entienden el lex. Al usar las herramientas automáticas, puede ignorar por completo m4 el 98% del tiempo. ¡En el 2% restante, también puedes ignorar m4! Por lo general, si te encuentras teniendo problemas relacionados con m4, es porque estás haciendo algo fundamentalmente erróneo. –
@WilliamPursell después de un par de años desde que pregunté esto, tiendo a estar de acuerdo. Pero el problema persiste: es demasiado fácil pasar por una ruta fundamentalmente equivocada al usarlo. Y, cuando quieres configurar realmente el control de compilación granular, finalmente presionas M4. A menos que me haya perdido algo? –
@TimPost Tuve que lidiar con un argumento similar años atrás. Nadie quería aprender M4 (ni nada si pudiera ser ayudado). El proyecto se convirtió en una combinación de scripts de bash y python, además de una espantosa aplicación de C++ que básicamente utilizaba 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 llamaba a python y scripts de shell a través de 'system (2)'), cambié este lío con un script de 200 líneas M4. Nunca aceptaré "no queremos aprenderlo" como una excusa válida. – DevNull