c++ github makefile automake

c++ - ¿Cómo superar la advertencia "''aclocal-1.15'' no se encuentra en su sistema"?



github makefile (9)

2017 - High Sierra

Es realmente difícil hacer que autoconf 1.15 funcione en Mac. Contratamos a un experto para que funcione. Todo funcionó muy bien.

Más tarde, pasé a actualizar una Mac a High Sierra.

¡La tubería de Docker dejó de funcionar!

Aunque autoconf 1.15 funciona bien en Mac.

Como arreglar,

Respuesta corta, simplemente destrocé el repositorio local y revisé el repositorio nuevamente.

Esta sugerencia se observa en la combinación de esta página de control de calidad y en otros lugares.

¡Entonces funcionó bien!

Es probable que tenga algo que ver con el aclocal.m4 y archivos similares . (Pero quién sabe realmente). Continuamente masajeé esos archivos ... pero nada.

Por alguna razón desconocida si solo rasca su repositorio y obtiene el repositorio nuevamente: ¡todo funciona!

Intenté durante horas cada combinación de tocar / eliminar, etc., los archivos en cuestión, pero no. ¡Solo echa un vistazo al repositorio desde cero!

Estoy tratando de ejecutar un programa c ++ en github. (disponible en el siguiente enlace https://github.com/mortehu/text-classifier )

Tengo un mac y estoy tratando de ejecutarlo en la terminal. Creo que he descargado autoconf y automake, pero no estoy seguro. Para ejecutar el programa, voy a la carpeta correcta en la terminal y luego ejecuto

./configure && make

Pero me sale el error:

ADVERTENCIA: ''aclocal-1.15'' no se encuentra en su sistema. Solo debería necesitarlo si modificó ''acinclude.m4'' o ''configure.ac'' o archivos m4 incluidos en ''configure.ac''. El programa ''aclocal'' es parte del paquete GNU Automake: http://www.gnu.org/software/automake También requiere GNU Autoconf, GNU m4 y Perl para ejecutarse: http://www.gnu.org/software/autoconf http://www.gnu.org/software/m4/ http://www.perl.org/ make: *** [aclocal.m4] Error 127

Tengo xcode y g ++ y todas las cosas necesarias para ejecutar programas en c, pero como probablemente sea obvio, no tengo idea de lo que estoy haciendo.

¿Cuál es la forma más fácil y sencilla de ejecutar el programa en el enlace anterior? Me doy cuenta de que viene con un archivo Léame y un ejemplo de uso, pero no puedo hacer que funcione.

2018, otra solución más ...

https://github.com/apereo/mod_auth_cas/issues/97

en algunos casos simplemente corriendo

$ autoreconf -f -i

y nada más ... resuelve el problema.

Lo hace en el directorio /pcre2-10.30 .

Qué pesadilla.

(Por lo general, esto no resolvió el problema en 2017, pero ahora parece resolver el problema, arreglaron algo. Además, parece que su Dockerfile debería comenzar con "FROM ibmcom / swift-ubuntu"; anteriormente tenía que dar cierta versión / dev-build para que funcione.)

A menudo, no necesita herramientas auto* y la solución más simple es simplemente ejecutar touch aclocal.m4 configure en la carpeta correspondiente (y también ejecutar touch en Makefile.am y Makefile.in si existen). Esto actualizará la marca de tiempo de aclocal.m4 y le recordará al sistema que aclocal.m4 está actualizado y no necesita ser reconstruido. Después de esto, probablemente sea mejor vaciar el directorio de build y volver a ejecutar la configure desde cero después de hacer esto. Me encuentro con este problema regularmente. Para mí, la causa raíz es que copio una biblioteca (por ejemplo, código mpfr para gcc ) de otra carpeta y las marcas de tiempo cambian.

Por supuesto, este truco no es válido si realmente necesita regenerar esos archivos, tal vez porque los ha cambiado manualmente. Pero es de esperar que los desarrolladores del paquete distribuyan archivos actualizados.

Y, por supuesto, si desea instalar automake y amigos, utilice el administrador de paquetes apropiado para su distribución.

Instale aclocal que viene con automake:

brew install automake # for Mac apt-get install automake # for Ubuntu

Inténtalo de nuevo:

./configure && make

Antes de ejecutar ./configure intente ejecutar autoreconf -f -i . El programa autoreconf ejecuta automáticamente autoheader, aclocal, automake, autopoint y libtoolize según sea necesario.

Editar para agregar: esto generalmente se produce al extraer el código de Git en lugar de extraerlo de un archivo .zip o .tar.gz . Para activar las reconstrucciones cuando los archivos cambian, Git no conserva las marcas de tiempo de los archivos, por lo que la secuencia de comandos de configure puede parecer desactualizada. Como otros han mencionado, hay formas de evitar esto si no tiene una versión suficientemente reciente de autoreconf .

Otra edición: este error también puede ser causado al copiar la carpeta de origen extraída de un archivo con scp a otra máquina. Las marcas de tiempo se pueden actualizar, lo que sugiere que es necesaria una reconstrucción. Para evitar esto, copie el archivo y extráigalo en su lugar.

Creo que el comando táctil es la respuesta correcta, por ejemplo, hacer algo como

touch --date="`date`" aclocal.m4 Makefile.am configure Makefile.in

antes de [./configure && make].

Barra lateral I: de lo contrario, estoy de acuerdo con @kaz: agregando dependencias para aclocal.m4 y / o configure y / o Makefile.am y / o Makefile.in hace suposiciones sobre el sistema de destino que pueden ser inválidas. Específicamente, esos supuestos son

1) que todos los sistemas de destino tienen herramientas automáticas,

2) que todos los sistemas de destino tienen la misma versión de autotools (por ejemplo, automake.1.15 en este caso).

3) que si (1) o (2) no son verdaderos para ningún usuario, que el usuario está extrayendo el paquete de un formato TAR o ZIP producido por el mantenedor que mantiene las marcas de tiempo de los archivos relevantes, en cuyo caso todo el autotool / configure Las dependencias /Makefile.am/Makefile.in en el Makefile configurado generado se satisfarán antes de que se emita el comando make.

La segunda suposición falla en muchos sistemas Mac porque automake.1.14 es el "último" para OSX (al menos eso es lo que veo en MacPorts, y aparentemente lo mismo es cierto para brew).

La tercera suposición falla espectacularmente en un mundo con Github. Este fracaso es un ejemplo de una mentalidad de "todos piensan que son normativos"; específicamente, los mantenedores, que son la única clase de usuarios que deberían necesitar editar Makefile.am, ahora han puesto a todos en esa clase.

Quizás haya una opción en autowhatever que evite que estas dependencias se agreguen a Makefile.in y / o Makefile.

Barra lateral II [Por qué @kaz tiene razón]: por supuesto, para mí y para otros expertos, es obvio que simplemente intente una secuencia de comandos [táctiles] para engañar al Makefile configurado de nuevo para que vuelva a ejecutar la configuración y las herramientas automáticas. Pero ese no es el punto de configuración; el punto de configuración es asegurar que tantos usuarios en tantos sistemas diferentes como sea posible puedan simplemente hacer [./configure && make] y seguir adelante; la mayoría de los usuarios no están interesados ​​en "afeitarse el yak", por ejemplo, depurar supuestos defectuosos de los desarrolladores de herramientas automáticas.

Barra lateral III: se podría argumentar que ./configure, ahora que las herramientas automáticas agregan estas dependencias, es la herramienta de compilación incorrecta para usar con paquetes distribuidos por Github.

Barra lateral IV: quizás los repositorios de Github basados ​​en la configuración deberían poner el comando táctil necesario en su archivo Léame, por ejemplo, https://github.com/drbitboy/Tycho2_SQLite_RTree .

El objetivo de Autotools es proporcionar un lenguaje arcano basado en macro M4 que finalmente se compila en un script de shell llamado ./configure . Puede enviar este script de shell compilado con el código fuente y ese script debe hacer todo lo posible para detectar el entorno y preparar el programa para la construcción. Las herramientas automáticas solo deben ser requeridas por alguien que quiera ajustar las pruebas y actualizar ese script de shell.

Derrota el punto de Autotools si GNU This y GNU That tienen que estar instalados en el sistema para que funcione. Originalmente, se inventó para simplificar la transferencia de programas a varios sistemas Unix, con los que no se podía contar con nada. Incluso las construcciones utilizadas por el código de shell generado en ./configure tuvieron que seleccionarse con mucho cuidado para asegurarse de que funcionarían en cada shell viejo roto en casi todas partes.

El problema con el que se está encontrando se debe a algunos pasos rotos de Makefile inventados por personas que simplemente no entienden para qué sirven Autotools y el papel del script final ./configure .

Como solución alternativa, puede acceder al Makefile y hacer algunos cambios para eliminar esto. Como ejemplo, estoy construyendo el jefe de Git de GNU Awk y me encuentro con este mismo problema. Sin embargo, apliqué este parche a Makefile.in y puedo make gawk éxito:

diff --git a / Makefile.in b / Makefile.in

index 5585046..b8b8588 100644 --- a/Makefile.in +++ b/Makefile.in @@ -312,12 +312,12 @@ distcleancheck_listfiles = find . -type f -print # Directory for gawk''s data files. Automake supplies datadir. pkgdatadir = $(datadir)/awk -ACLOCAL = @ACLOCAL@ +ACLOCAL = true AMTAR = @AMTAR@ AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@ -AUTOCONF = @AUTOCONF@ -AUTOHEADER = @AUTOHEADER@ -AUTOMAKE = @AUTOMAKE@ +AUTOCONF = true +AUTOHEADER = true +AUTOMAKE = true AWK = @AWK@ CC = @CC@ CCDEPMODE = @CCDEPMODE@

Básicamente, cambié las cosas para que el comando inofensivo de shell true se sustituya por todos los programas de Autocompletar.

¡Los pasos de compilación reales para Gawk no necesitan el relleno automático! Solo está involucrado en algunas reglas que se invocan si partes de Auto-stuff han cambiado y necesitan ser reprocesadas. Sin embargo, el Makefile está estructurado de tal manera que falla si las herramientas no están presentes.

Antes del parche anterior:

$ ./configure [...] $ make gawk CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash /home/kaz/gawk/missing aclocal-1.15 -I m4 /home/kaz/gawk/missing: line 81: aclocal-1.15: command not found WARNING: ''aclocal-1.15'' is missing on your system. You should only need it if you modified ''acinclude.m4'' or ''configure.ac'' or m4 files included by ''configure.ac''. The ''aclocal'' program is part of the GNU Automake package: <http://www.gnu.org/software/automake> It also requires GNU Autoconf, GNU m4 and Perl in order to run: <http://www.gnu.org/software/autoconf> <http://www.gnu.org/software/m4/> <http://www.perl.org/> make: *** [aclocal.m4] Error 127

Después del parche:

$ ./configure [...] $ make gawk CDPATH="${ZSH_VERSION+.}:" && cd . && true -I m4 CDPATH="${ZSH_VERSION+.}:" && cd . && true gcc -std=gnu99 -DDEFPATH=''".:/usr/local/share/awk"'' -DDEFLIBPATH="/"/usr/local/lib/gawk/"" -DSHLIBEXT="/"so"/" -DHAVE_CONFIG_H -DGAWK -DLOCALEDIR=''"/usr/local/share/locale"'' -I. -g -O2 -DNDEBUG -MT array.o -MD -MP -MF .deps/array.Tpo -c -o array.o array.c [...] gcc -std=gnu99 -g -O2 -DNDEBUG -Wl,-export-dynamic -o gawk array.o awkgram.o builtin.o cint_array.o command.o debug.o dfa.o eval.o ext.o field.o floatcomp.o gawkapi.o gawkmisc.o getopt.o getopt1.o int_array.o io.o main.o mpfr.o msg.o node.o profile.o random.o re.o regex.o replace.o str_array.o symbol.o version.o -ldl -lm $ ./gawk --version GNU Awk 4.1.60, API: 1.2 Copyright (C) 1989, 1991-2015 Free Software Foundation. [...]

Aquí vamos. Como puede ver, las líneas de comando CDPATH= allí son donde se invocó el Auto-stuff, donde ve los comandos true . Estos informan una finalización exitosa, por lo que simplemente se cae a través de esa basura para hacer la construcción maldita, que está perfectamente configurada.

Hice make gawk porque hay algunos subdirectorios que se crean que fallan; el truco tiene que repetirse para sus respectivos Makefiles.

Si te encuentras con este tipo de cosas con un tarball prístino y oficial del programa de sus desarrolladores, entonces quéjate. Simplemente debe descomprimir, ./configure y make sin que tenga que parchear nada o instalar ningún material de Automake o Autoconf.

Idealmente, un tirón de su cabeza Git también debería comportarse de esa manera.

Puede instalar la versión que necesita fácilmente:

Primero obtenga la fuente:

$ wget https://ftp.gnu.org/gnu/automake/automake-1.15.tar.gz

Descomprimirlo:

$ tar -xzvf automake-1.15.tar.gz

Construir e instalar:

$ cd automake-1.15 $ ./configure --prefix=/opt/aclocal-1.15 $ make $ sudo mkdir -p /opt $ sudo make install

Úselo:

$ export PATH=/opt/aclocal-1.15/bin:$PATH $ aclocal --version

aclocal (GNU automake) 1.15

Ahora, cuando se llama a aclocal, obtienes la versión correcta.

Una respuesta genérica que puede aplicarse o no a este caso específico:

Como sugiere el mensaje de error, aclocal-1.15 solo debería ser necesario si modificó los archivos que se usaron para generar aclocal.m4

Si no modifica ninguno de esos archivos (incluido configure.ac), entonces no debería necesitar tener aclocal-1.15.

En mi caso, el problema no era que ninguno de esos archivos fuera modificado, sino que de alguna manera la marca de tiempo en configure.ac era 6 minutos más tarde en comparación con aclocal.m4.

No he descubierto por qué, pero un clon limpio de mi repositorio de git resolvió el problema por mí. Tal vez algo relacionado con git y cómo creó archivos en primer lugar.

En lugar de volver a ejecutar autoconf y amigos, solo trataría de obtener un clon limpio y volvería a intentarlo .

También es posible que alguien haya cometido un cambio en configure.ac pero no haya regenerado el aclocal.m4, en cuyo caso de hecho debe volver a ejecutar automake y amigos.