PDF de programación - Autoconf y Automake: Cómo logré construir un tarball

Autoconf y Automake: Cómo logré

construir un tarball

Por shicefgo.

Liberada bajo licencia

http://creativecommons.org/licenses/by-nc-sa/2.5/

1. La idea

Este escrito ha surgido de la idea de anotar lo aprendido para llegar a realizar un paquete instalable de la
forma habitual en GNU/Linux, es decir, utilizando los comandos: tar -zxvf nombre_paquete.tar.gz,
entrando en el directorio correspondiente y ejecutando ./configure, make y, como root, make install
(recuerda: “no uses el nombre de root en vano”). Tomar apuntes para uno mismo es algo que está bien,
pero pienso que estaría todavía mejor si, con un pequeño esfuerzo añadido, esos apuntes contribuyeran a
que alguien más pueda orientarse en los vericuetos que uno ha ido explorando. Siempre que leo
documentación técnica, me encuentro que casi todo está escrito en la forma: “haz esto y luego aquello,
después esto otro, y así.” Es decir, una serie de instrucciones bien explicadas por alguien que conoce de
qué va la cosa. Cómo no soy experto en nada (alguien dijo que un experto es aquél que sabe cada vez
más sobre menos, hasta que termina sabiéndolo absolutamente todo sobre nada), he pensado que, en
lugar de decirte lo que hay que hacer, voy a contarte cómo lo he hecho yo. Si quieres, puedes seguir mis
pasos bajo tu propio riesgo, y puedes contar con que me esforzaré para que la lectura de “esto” no te
resulte demasiado tediosa.

2. Qué es un tarball

Se acostumbra a denominar “tarball” a un paquete preparado para ser compilado e instalado,
normalmente bajo un sistema Unix-GNU/Linux, cuyo nombre suele terminar en “.tar.gz”. La palabra
empezó siendo utilizada para referirse a los archivos construidos usando el comando tar. Originalmente,
esos archivos eran guardados en cinta, pero en la actualidad tar se utiliza ampliamente para acumular
una gran cantidad de archivos en uno solo preservando la información del sistema de ficheros, como
permisos del usuario y del grupo, fechas, y la estructura de directorios. De acuerdo con la filosofía Unix
de “un trabajo, un programa”, el comando tar no comprime, sólo empaqueta. Para comprimir se utiliza
gzip, del cual procede el sufijo “.gz”, y también bzip2, que da origen al sufijo “.bz2”. Y ya que estamos,

1

quizás le venga bien a alguien saber como descomprimir “del tirón” los archivos comprimidos con bzip2:
tar -jxvf nombre_archivo.tar.bz2.

Autoconf y Automake: Cómo logré construir un tarball

La ventaja de utilizar las autotools es que podemos poner nuestro programa a funcionar en cualquier
sistema con sabor Unix y, más generalmente, en cualquier sistema que tenga soporte para ellas,
consiguiendo una buena portabilidad y no teniendo que realizar el trabajo más que una sola vez. ¿Que ya
sabías todo esto? ¡Pues habérmelo dicho! :-).

3. Lo que hay que tener

Además del programa que vayamos a “empaquetar”, necesitamos tener instalados, obviamente, un
compilador y los paquetes autoconf y automake. El compilador al que voy a referirme será gcc, y el
lenguaje de programación el C, aunque lo mismo podría servir para C++. También será útil disponer de
autoconf-archive, autobook (el libro de las autotools), libtool, y no sería una mala idea instalarse la
documentación relativa a estos paquetes.

También se asume alguna idea de programación en la shell Bash, y un somero conocimiento de los
makefiles, como por ejemplo el detalle de que una orden ejecutable debe ir precedida de una tabulación.

4. Las primeras dificultades

Cuando conseguí escribir en C algo casi digno de ser llamado “un programa” (el almanaque, sin ir más
lejos), me encontré con que, debido a una acumulación de circunstancias, llegó a encontrarse disponible
para quien lo quisiera a través de los foros de Fentlinux, y la compilación se efectuaba de una forma
bastante chapucera, con un Makefile de andar por casa que, si bien compilaba, no permitía chequear
dependencias y avisar al usuario de que le faltaba tal o cual cosa, en caso de que así fuera.

Entonces llegó el día en que me decidí a meterle mano al asunto. Era un día como otro cualquiera, no
recuerdo que tuviese nada de especial, pero me pareció que se había adelantado un poco a mis
previsiones, ya que no tenía ni idea de por donde empezar. Cuando le meto mano a algo es porque ya
creo saber lo suficiente como para intentarlo, lo que me ha llevado a no pocas frustraciones y a leer el
inglés contra mi voluntad, ya que eso me hace perder más tiempo que leyendo en español, entre que
encuentro el significado literal y consigo interpretarlo, que no sé por qué el inglés tiene que ser tan raro.
Y cuando utilizo un traductor automático, me salen cosas como esto: “Por supuesto, los ajustes
de defecto no satisfarán cada uno, así que las opciones se pueden agregar a ’
configuran ’ la escritura, y las cosas como compile las banderas pueden ser
pased en variables del environmnet.” Y esta es de las que se entienden.

A continuación mostraré el esquema general del Makefile que conseguía compilar mi programilla antes
de que hubiese logrado utilizar las autotools. (Aviso: Una auténtica y verdadera chapuza, pero lo hice yo
sólo). La compilación se realizaba a partir de tres archivos: un Makefile y otro llamado makeinclude en

2

Autoconf y Automake: Cómo logré construir un tarball

el directorio raíz de la aplicación, y otro Makefile en el directorio de los archivos fuentes (src). Lo del
makeinclude se basaba en la genial idea de que, si llegaba a desarrollar el proyecto en varios directorios
con archivos fuentes a compilar en cada uno de ellos (iluso que era uno), sólo tendría que incluirlo en el
Makefile de cada directorio con fuentes, con alguna pequeña modificación tal vez, y trabajo de escritura
que me ahorraba. Sin duda que esta idea tendrá sus detractores, pero como sólo tuve que utilizar un
directorio de archivos fuentes, funcionó a la perfección. Veamos ahora el código del Makefile principal:

DIRS = src

all:

for dir in $(DIRS); do\

echo "=== Compilando en $$dir ===";\
(cd $$dir; $(MAKE) $(MFLAGS)) || break;\

done

clean:

rm -f ./src/*.o

El del makeinclude:

CC = gcc
NOMBRE_EJECUTABLE = ../almanaque
OPTIM = -Wall -Wunused -Wmissing-prototypes -O2
GTKFLAGS = ‘pkg-config --cflags gtk+-2.0‘
GDAFLAGS = ‘pkg-config --cflags libgda‘
GTKLDADD = ‘pkg-config --libs gtk+-2.0‘
GDALDADD = ‘pkg-config --libs libgda‘

Y, por último, el Makefile dentro del directorio src:

include ../makeinclude

FUENTES = \
gtkmisc.c \
fecha.c \
cantidad.c \
gregoriano.c \
main.c

OBJS = ${FUENTES:.c=.o}
CFLAGS = ${OPTIM} ${GTKFLAGS} ${GDAFLAGS}
LDADD = ${GTKLDADD} ${GDALDADD}
EJECUTABLE = ${NOMBRE_EJECUTABLE}

all: ${OBJS}

${CC} -o ${EJECUTABLE} ${OBJS} ${LDADD}

.c.o:

${CC} ${CFLAGS} -c $<

3

Autoconf y Automake: Cómo logré construir un tarball

Como se dijo antes, las líneas “${CC} -o ${EJECUTABLE} ${OBJS} ${LDADD}” y “${CC}
${CFLAGS} -c $<” deben ir precedidas de una tabulación, no de espacios en blanco. Esto me permitía
compilar y también borrar los archivos .o con un make clean, pero cuando modificaba un archivo de
cabecera (.h), tenía que compilarlo todo con make -W. Un esquema como este, o parecido, puede ser útil
y hasta recomendable al comienzo de un proyecto para compilar las primeras veces, pero una vez que la
cosa va tomando forma y, sobre todo, si queremos poner nuestro trabajo a disposición de otras personas,
se hace necesario utilizar algo mejor hecho y, por qué no, más profesional. No es mi propósito entrar en
los detalles de la creación de Makefiles, de ahí que no comente el código anterior, para eso hay en
internet gran cantidad de tutoriales a partir de los cuales cualquiera que ponga el suficiente interés podrá
obtener los conocimientos necesarios para crearse los suyos propios. Así pues, mis primeras dificultades
estaban relacionadas con los archivos de cabecera, que no eran tenidos en cuenta, y con la imposibilidad
de chequear dependencias, ya que lo de la portabilidad ni me lo había planteado.

5. Así fue como lo hice

Una vez situado en el directorio raíz de la aplicación (no lo he dicho antes, pero es altamente conveniente
organizar el proyecto dentro de un directorio, a partir del cual “cuelguen” los demás que sean necesarios,
entre ellos el de los fuentes, típicamente llamado src), ejecuté los siguientes pasos, no sé si exactamente
por este orden, pero este es el orden que pienso seguir en lo sucesivo.

Primero creo unos archivos necesarios para la correcta ejecución de automake con el siguiente comando:

~$ touch README AUTHORS NEWS THANKS ChangeLog

En el momento de su creación estarán vacíos, lógicamente, y su contenido suele ser:

• README: Explicaciones que el autor considere necesario incluir para la correcta compilación e

instalación del programa, así como cualquier otra información técnica útil al usuario final.

• AUTHORS: Los nombres del autor, o autores, de la aplicación.

• NEWS: Cambios visibles al usuario, con los más recientes al principio del archivo (ordenados de último

a primero).

• THANKS: Agradecimientos especiales del autor o autores a personas o entidades que de alguna manera

hayan contribuido a la realización del proyecto, pero que no pertenezcan a AUTHORS o a
MAINTAINERS.

• ChangeLog: Un registro, ordenado por fechas y también de último a primero, de todos los cambios

que se van realizando en la aplicación, sean o no visibles al usuario.

Opcionalmente se pueden incluir unos archivos más, ya que automake funcionará perfectamente aunque
no existan: MAINTAINERS y HACKING. El primero contendría los nombres de todos los responsables del
proyecto, no sólo de los autores del código y diseño, y en el segundo irían instrucciones para otros
programadores que quieran realizar modificaciones en el programa. En él se pueden incluir cosas tales

4

como notas sobre el estilo de programación adoptado (por si alguien no lo advierte leyendo el código),
para qué tipo de cambios sería conveniente pedir permiso a los autores, y cosillas de esa índole.

Autoconf y Automake: Cómo logré construir un tarball

Ninguno de es