Automake

http://sources.redhat.com/automake/

1. Introducción

automake conoce los ficheros que ha de generar a través de su relación con autoconf.

Gran parte de un Makefile.am consiste en asignación de variables, el nombre de las cuales proporciona información a automake sobre su propósito y función. Esa cualidad se rige por el denominado esquema uniforme de nomenclatura.

automake se utiliza no solo para construir los programas, sino también para construir los paquetes que se distribuyen, es decir, prepara los objetivos dist, distclean, etc. Mediante el mencionado sistema de nomenclatura de variables, determina qué ficheros se distribuyen y cuáles no.

2. Relación con autoconf

configure.ac ha de incluir la macro AM_INIT_AUTOMAKE si se utiliza automake en el proyecto.

El propio automake provee algunas macros (que comienzan con AM_) de autoconf para sus propios intereses, a traves de aclocal.m4, construído por aclocal en base al contenido de configure.ac por lo que es posible que cuando se modifica éste con macros provenientes de automake sea necesario el uso de aclocal antes de autoconf.

Ademas, automake lee configure.ac para diversas cosas:

• de AM_INIT_AUTOMAKE lee opciones de trabajo ( http://sources.redhat.com/automake/automake.html#Options ), que también pueden asignarse. Si protesta porque no lo encuentra y, sin embargo, sí está, probablemente es que no se ha ejecutado aclocal, que es quien incluye esa macro en aclocal.m4.
• a partir de AC_CONFIG_FILES elabora la lista de makefiles que se han de generar: cada fichero especificado ahí que tenga un equivalente con extensión .am
• todos los inputs de esos ficheros se incluyen en el objetivo dist y los generados se eliminan con el objetivo distclean

Todos los detalles sobre este apartado pueden verse aquí. Como, por ejemplo, qué ocurre si en la definición de entradas o salidas de una macro AC_CONFIG_FILES intervienen variables.

E incluso ejecuta autoconf para seguir el uso de distintas macros y tomar medidas apropiadas en el Makefile.in que genera (véase este apartado para los detalles.

3. Opciones de interes

foreign

relaja un poquito las reglas de paquetes GNU

subdir-objects

Crea los ficheros objeto en el mismo directorio donde está la fuente (mejor ponerla siempre, digo cho)

4. Definición de programas y librerías

4.1. esquema uniforme de nomenclatura

Básicamente, consiste en que un determinado tipo de objetivos tiene un nombre llamado primary (PROGRAMS,LIBRARIES, SCRIPTS, ...), al que precede un prefijo que indica su ubicación de instalación: bin_ para los que se ubicaran en bindir (libexecdir, pkgdatadir, ...) o bien noinst_ si no se han de instalar. Este esquema es extensible; se puede definir una variable xxxdir y luego utilizar el prefijo xxx_ con un primary.

A su vez, cada uno de los targets asociados a un primary se convierte, a su vez, en prefijo para otros primaries. Así un programa xyx incluído en bin_PROGRAMS define sus fuentes mediante xyz_SOURCES. Tengase en cuenta que si xyz fuera xy.z en bin_PROGRAMS, como prefijo sería xy_z.

Para mas información sobre primaries y prefijos, véase este apartado del manual de autoconf

4.2. Principales variables implicadas

xyz_SOURCES

excepto en el caso de que un programa se compile solo a partir del fuente homónimo, tanto programas como librerías utilizan esta variable para listar los fuentes que se utilizan para su compilación.

EXTRA_xyz_SOURCES

se utiliza para listar fuentes que pueden o no incluirse a la hora de compilar según determine configure

xyz_LDADD

para programas, objetos y/o librerías adicionales utilizados en el enlazado del programa

xyz_LIBADD

para librerías, objetos y/o librerías adicionales utilizados en el enlazado del programa

xyz_DEPENDENCIES

permite establecer dependencias de ficheros que no son utilizados para la construcción del programa o librería

xyz_xFLAGS

permite sobre-escribir las variables AM_xFLAGS para un programa o librería determinados; si ademas se desea que se utilicen los flags estándar, han de añadirse específicamente: xyz_CCFLAGS = --myflag $(AM_CCFLAGS)

Especial mención merecen xyz_LDFLAGS, utilizados para el enlazado, y xyz_LIBTOOLFLAGS, utilizados para la invocación de libtool

La lista completa de variables puede verse aquí

5. instalación

Los directorios de instalación deben manejarse siempre mediante variables predefinidas, de forma que el usuario pueda modificar ciertas variables y con ello ubicar la instalación donde le venga bien.

Si se utiliza autoconf, estas variables se escriben en Makefile.am con la sintaxis indicada para su sustitución por configure (p.e.: @bindir@ ), mientras que si no se usa, ha de hacerse con la sintaxis de make ( p.e.: $(bindir) ).

5.1. Ubicaciones estándar

prefix

es la raíz a partir de la cual se construyen los valores por defecto de todos los demas, algunos de ellos a traves de exec_prefix que, por defecto, tiene el mismo valor que prefix, usualmente, /usr/local

bindir, sbindir, libexecdir

Directorios para ejecutables. usualmente, /usr/local/bin, /usr/local/sbin/ y /usr/local/libexec (éste último, indicado para programas usualmente ejecutados por otros programas, en lugar de por usuario o administrador).

datarootdir, datadir

Datos de solo lectura no indicados para adaptar localmente por el administrador. Normalmente, son la misma ubicación (/usr/local/share), pero el segundo está indicado para ficheros cuyo carácter es específico del programa (es decir, no pertenecen a un tipo general, como páginas de manual, fuentes, etc.), y de esa forma se puede especificar una ubicación diferente a la de los ficheros que cumplen una función estándar.

sysconfdir

Datos de solo lectura adaptables por el administrador al sistema local. Habitualmente, /usr/local/etc

localstatedir

Datos de lectura / escritura. El primero puede ser /var/local o /usr/local/var.

includedir, oldincludedir

Suelen ser, respectivamente, /usr/local/include/ y /usr/include/.

docdir, htmldir, divdir, pdfdir, psdir

Usualmente todos /usr/local/share/doc/pkgname

libdir

Usualmente /usr/local/lib

localedir

Para mensajes localizados específicos del programa. Suele ser $(datarootdir)/locale

srcdir

eso

5.2. Objetivos de instalación

Conviene no olvidar que la instalación se ejecuta sí o sí. Es decir, los ficheros incluídos se copian a su destino siempre, por lo que es conveniente tratar de forma específica aquellos ficheros que puedan ser modificados por el usuario y que, por tanto, no conviene machacar con una re-instalación de la aplicación.

Una solución es utilizar el objetivo install-data-hook, que se ejecuta despues de la instalación de datos para instalar condicionalmente tales ficheros, despues de ser copiados a algun otro lugar. p.e.:

dist_doc_DATA = un_fichero

install-data-hook:
        test -e @localstatedir@/un_fichero 
   cp @docdir@/un_fichero @localstatedir@/

Se utilizan dos objetivos de instalación: install-data e install-exec, ambos recogidos en el objetivo general install.

install-data

Recoge los ficheros independientes de arquitectura, es decir, los prefijos predeterminados data, info, man, include, oldinclude, pkgdata y pkginclude.

install-exec

y éste para material específico de arquitectura, es decir, los prefijos predeterminados bin, sbin, libexec, sysconfdir, localstate, lib y pkglib

6. librerías

Para librerías estáticas se utiliza el primary LIBRARIES, que funciona básicamente igual que PROGRAMS, mientras que para librerías compartidas lo suyo es utilizar libtool, en cuyo caso se usa el primary LTLIBRARIES. En realidad, con libtool pueden generarse al mismo tiempo librerías estáticas y compartidas sin ningún esfuerzo: permite construir una y/u otra modalidad difiriendo la decisión hasta el momento de la compilación por parte del usuario. Sus librerías tienen la extensión .la, y los objetos compilados .lo.

Tanto en la documentación de libtool como en la de automake hay capítulos dedicados al uso de libtool con automake.

Aparte de _SOURCES o _LDADD, otro sufijo de variable utilizada para definir una librería es _LIBTOOLFLAGS, que, si existe, reemplaza a AM_LIBTOOLFLAGS.

6.1. Instalación

Para el caso de las compartidas, es importante recordar que libtool debe saber su ubicación de destino en el momento de construirla, para lo cual automake ha de saberlo a fin de proporcionarle a libtool la opción -rpath adecuada, por lo que conviene evitar incluir estas librerías mediante variables, que impiden a automake saber cual va a ser su ubicación.

Para que las librerías compartidas puedan ser utilizadas una vez instaladas, han de poder ser localizadas por el sistema cuando se necesitan, hay dos caminos: o el ejecutable que las necesita lleva información de la localización de la librería (enlazado con -rpath) o se le notifica al sistema donde está la librería mediante

ldconfig -n /path/al/dir

Ademas, libtool tb facilita el uso de librerías de carga dinámica (como plugins). Eso se le hace saber así:

lib_LTLIBRARIES = libxxx.la unplugin.la
unplugin_la_LDFLAGS = -module