Dos o tres cosas que posiblemente no sepas sobre GNU make

Make es una herramienta venerable que, fiel al espíritu Unix de los años 80, hace una cosa y la hace bien. Lo que hace es generar ficheros comparando las fechas del generador y el generado y, en el caso de que el generado sea más antiguo, aplicar una receta que es una orden del intérprete de órdenes. Es decir:

generado: generador
    haz-cosa-con-el generador --target=generado

De algo tan simple se puede eventualmente crear un fichero relativamente complicado, que resuelva dependencias entre generadores y generados y eventualmente genere algo con el mínimo trabajo posible. Make es también capaz de trabajar en paralelo y todo esto hace que esté presente en prácticamente todos los sistemas linux. Teclear make — version escribirá algo así:

GNU Make 3.81
Copyright © 2006 Free Software Foundation, Inc.
Este es software libre; consulte en el código fuente las condiciones de copia.
NO hay garantía; ni siquiera para MERCANTIBILIDAD o EL CUMPLIMIENTO DE
ALGÚN PROPÓSITO PARTICULAR.

Este programa fue construido para x86_64-pc-linux-gnu

O posiblemente algo más moderno; la última versión es la 4.2.1, aunque las versiones no corren con la misma velocidad que con otros programas; de la 3 a la 4 han pasado casi 20 años. Esta venerabilidad causa algunos problemas, que casi siempre se resumen en “hay un espacio donde no debiera”. Por eso conviene usar editores como emacs que te avisan en tales circunstancias

Siempre es un espacio

Sigue siendo una herramienta imprescindible para automatizar tareas aún así. Siempre que te encuentres tecleando frecuentemente una secuencia de dos órdenes o más, es el momento de hacer un Makefile. Así que dejamos estas dos o tres recetas que puede que no conozcas.

Sacar copias de seguridad

Siempre conviene sacar copias de seguridad de todo. Si puede ser, en varios lugares diferentes. Es fácil con un Makefile:

El truco aquí es que en unix los directorios también son ficheros. La regla compara el directorio donde se va a copiar con el original. Se puede usar además esta sintaxis:

rsync -avz $< $@

Con el <, que parece una flecha, indicando el predecesor (¿lo pilláis?) y $@ el target u objetivo (parece una diana, ¿no?).

Lo que también podemos usar para generar ficheros .zip:

En este caso, si el fichero .zip es más antiguo que el fichero . (el que almacena el propio directorio) se genera el .zip. Se aconseja combinar las dos recetas para mayor seguridad.

Hacer pruebas y comandos opcionales según el resultado.

Es imprescindible probar todo antes de sincronizar los cambios en un repositorio. Y esto se aplica no sólo al código, también a la documentación. Podemos comprobar la ortografía, por ejemplo, usando hunspell:

En este clásico una-línea de bash usamos hunspell con un diccionario personal para comprobar los ficheros Markdown. Si todo está correcto, no devolverá ninguna palabra y grep ., a su vez, estará calladito. Sin embargo, si hay alguna palabra que no esté en el diccionario la orden saldrá con un código incorrecto, exit 2. La intención de esto es, precisamente, usarlo para anidar Makefiles, como el siguiente, que hace commit sólo y exclusivamente si todo va bien.

Ejecutando esto con

make -f 4.mk msg=’The testeo’ commit

que, lo sé, es un poco largo, primero se probará usando git status si realmente ha habido algún cambio. Aquí es en uno de los casos que se nota la venerabilidad de make: sólo se pueden comprobar en los precedentes ficheros, no se pueden evaluar funciones ni nada por el estilo. Así que para comprobar si ha habido algún cambio en el repositorio tenemos que usar el fichero de pega status, que se crea si ha habido algún cambio. Si es así, se llama al otro Makefile que devolverá el estado “2” si ha habido algún error y se interrumpirá; si no lo hay, usa la variable msg para hacer commit. Lo que hace aparente que, aunque hayamos escrito mucho (podría ser menos si el fichero se llamara simplemente Makefile) realmente estamos haciendo un montón de cosas, y todo a base de unas pocas líneas del Makefile y entender los códigos de salida de bash (cosa que, por otro lado, siempre viene bien conocer).

Generar ficheros de texto.

Trabajar con ficheros LaTeX implica compilar, pasar la bibliografía, compilar y voler a compilar para que todas las referencias estén bien en el PDF de salida. Este fichero lo soluciona:

Cambiándole el nombre a Makefile y llamándolo con

make paper.pdf

te usará las reglas implícitas para generar PDFs desde ficheros .tex, con el truco de la segunda línea,

bibtex $(basename $<)

Que te quita la extensión .tex, porque bibtex es un poco delicado y tiene que usarse de esa forma.

Concluyendo

En el momento que te encuentres repitiendo secuencias de dos órdenes muy a menudo, es el momento de crear un script de bash para automatizarlo. Pero si esas secuencias tienen dependencias temporales y además tienen reglas automáticas para generar ficheros de un tipo desde otro tipo, make al rescate. Además, tiene reglas implícitas para todo tipo de ficheros, por ejemplo ficheros Ratfor, que nunca se acuerda uno de cómo se generan, por lo que en ocasiones simplemente escribiendo make, sin Makefile ni nada, hará algo relativamente razonable. Merece la pena conocer sus reglas de funcionamiento básico y emplearlo a menudo, para no olvidarse.