¿Pueden las herramientas automáticas crear archivos MAKE multiplataforma?
https://stackoverflow.com/questions/324134
-
11-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Tengo un proyecto de complemento que he estado desarrollando durante algunos años en el que el complemento funciona con numerosas combinaciones de [versión de aplicación principal, versión de biblioteca de terceros, 32 bits frente a 64 bits]. ¿Hay alguna forma (limpia) de usar autotools para crear un único archivo MAKE que genere todas las versiones del complemento?
Por lo que puedo deducir de hojear la documentación de autotools, la aproximación más cercana a lo que me gustaría es tener N copias independientes del proyecto, cada una con su propio archivo MAKE. Esto parece un poco subóptimo para las pruebas y el desarrollo, ya que (a) necesitaría propagar continuamente los cambios de código en todas las diferentes copias y (b) hay mucho espacio desperdiciado al duplicar el proyecto tantas veces. ¿Hay una mejor manera?
EDITAR:
He estado lanzando mi propia solución durante un tiempo en la que tengo un sofisticado archivo MAKE y algunos scripts de Perl para buscar varias versiones de bibliotecas de terceros, etc. Como tal, estoy abierto a otras soluciones que no sean de herramientas automáticas. Para otras herramientas de compilación, me gustaría que sean muy fáciles de instalar para los usuarios finales. Las herramientas también deben ser lo suficientemente inteligentes como para buscar varias bibliotecas y encabezados de terceros sin una gran cantidad de problemas. Estoy buscando principalmente una solución de Linux, pero una que también funcione para Windows y / o Mac sería una ventaja.
Otros consejos
Si su pregunta es:
¿Puedo usar las herramientas automáticas en alguna máquina A para crear un único archivo MAKE universal que funcione en todas las otras máquinas?
entonces la respuesta es "No". Las herramientas automáticas ni siquiera fingen tratar de hacer eso. Están diseñados para contener código portátil que determinará cómo crear un archivo MAKE viable en la máquina de destino.
Si su pregunta es:
¿Puedo usar las herramientas automáticas para configurar el software que necesita ejecutarse en diferentes máquinas, con diferentes versiones del software primario con el que funciona mi complemento, además de varias bibliotecas de terceros, sin mencionar problemas de 32 bits frente a 64 bits?
entonces la respuesta es "Sí". Las herramientas automáticas están diseñadas para poder hacer eso. Además, funcionan en Unix, Linux, MacOS X, BSD.
Tengo un programa, SQLCMD (que es anterior al programa de Microsoft del mismo nombre por una década o más), que funciona con las bases de datos IBM Informix. Detecta la versión del software del cliente (llamado IBM Informix ESQL / C, parte del IBM Informix ClientSDK o CSDK) instalado, y si es de 32 bits o de 64 bits. También detecta qué versión del software está instalada y adapta su funcionalidad a lo que está disponible en el producto de soporte. Es compatible con versiones que se han lanzado durante un período de aproximadamente 17 años. Está autoconfigurado: tuve que escribir algunas macros de autoconf para la funcionalidad de Informix y para un par de otros artilugios (sincronización de alta resolución, presencia de / dev / stdin, etc.). Pero es factible.
Por otro lado, no intento liberar un solo archivo MAKE que se ajuste a todas las máquinas y entornos de los clientes; hay demasiadas posibilidades para que eso sea sensato. Pero autotools se encarga de los detalles para mí (y para mis usuarios). Todo lo que hacen es:
./configure
Eso es más fácil que averiguar cómo editar el archivo MAKE. (Oh, durante los primeros 10 años, el programa se configuró a mano. Fue difícil para las personas hacerlo, a pesar de que tenía una configuración predeterminada bastante buena. Por eso me mudé a la configuración automática: hace que sea mucho más fácil personas para instalar.)
El Sr. Fooz comentó:
Quiero algo en el medio. Los clientes utilizarán múltiples versiones y bits de la misma aplicación base en la misma máquina en mi caso. No me preocupa la compilación cruzada, como la creación de binarios de Windows en Linux.
¿Necesita una compilación separada de su complemento para las versiones de 32 bits y 64 bits? (Supongo que sí, pero podría sorprenderme). Por lo tanto, debe proporcionar un mecanismo para que el usuario diga
./configure --use-tppkg=/opt/tp/pkg32-1.0.3
(donde tppkg es un código para su paquete de terceros, y el usuario puede especificar la ubicación). Sin embargo, tenga en cuenta la usabilidad: cuantas menos opciones tenga el usuario para proporcionar, el mejor; contra eso, no codifique cosas que deberían ser opcionales, como las ubicaciones de instalación. Por supuesto, busque en ubicaciones predeterminadas, eso es bueno. Y por defecto a la amargura de las cosas que encuentras. Tal vez si encuentra versiones de 32 bits y de 64 bits, entonces debería construir ambas, aunque eso requeriría una construcción cuidadosa. Siempre puede hacer eco de " Comprobando el paquete TP ... " e indique lo que encontró y dónde lo encontró. Entonces el instalador puede cambiar las opciones. Asegúrese de documentar en ' ./configure --help ' cuáles son las opciones; Esta es una práctica estándar de herramientas automáticas.
Sin embargo, no hagas nada interactivo; el script de configuración debería ejecutarse, informando lo que hace. El script Perl Configure (tenga en cuenta la letra mayúscula, es un sistema de configuración automática completamente separado) es uno de los pocos sistemas de configuración intensamente interactivos que quedan (y eso probablemente se deba principalmente a su herencia; si comienza de nuevo , lo más probable es que no sea interactivo). Tal sistema
¡Lo probamos y no funciona! Así que ahora usamos SCons .
Algunos artículos sobre este tema: 1 y 2
Editar: Un pequeño ejemplo de por qué amo SCons:
env.ParseConfig('pkg-config --cflags --libs glib-2.0')
Con esta línea de código, agrega GLib al entorno de compilación ( env ). Y no olvide la Guía del usuario lo cual es genial para aprender SCons (¡realmente no tienes que saber Python!). Para el usuario final, puede probar SCons con PyInstaller o algo así.
Y en comparación con make , usa Python, ¡entonces un lenguaje de programación completo! Con esto en mente, puede hacer todo (más o menos).
¿Alguna vez ha considerado utilizar un solo proyecto con múltiples directorios de compilación? si su proyecto de automake se implementa de manera adecuada (es decir, NO como gcc)
lo siguiente es posible:
mkdir build1 build2 build3
cd build1
../configure $(YOUR_OPTIONS)
cd build2
../configure $(YOUR_OPTIONS2)
[...]
puede pasar diferentes parámetros de configuración como incluir directorios y compiladores (compiladores cruzados, por ejemplo).
incluso puede ejecutar esto en una sola llamada de ejecución ejecutando
make -C build1 -C build2 -C build3
