Automake y archivos con el mismo nombre

Question

Tengo un proyecto de C ++ autoconf logró que yo estoy adaptando a compilar en anfitriones de FreeBSD. El sistema original de Linux, así que hizo una AM_CONDITIONAL distinguir el anfitrión que estoy construyendo y separar el código en el sistema de archivos específicos.

configure.ac

AC_CANONICAL_HOST
AM_CONDITIONAL([IS_FREEBSD],false)
case $host in
        *free*)    
            AC_DEFINE([IS_FREEBSD],[1],[FreeBSD Host])
            AM_CONDITIONAL([IS_FREEBSD],true)
            BP_ADD_LDFLAG([-L/usr/local/lib])
                ;;
esac

Makefile.am

lib_LTLIBRARIES=mylib.la
mylib_la_SOURCES=a.cpp \
                 b.cpp

if IS_FREEBSD
    mylib_la_SOURCES+=freebsd/c.cpp
else
    mylib_la_SOURCES+=linux/c.cpp
endif

Cuando corro automake falla con este tipo de mensaje:

Makefile.am: object `c.lo' created by `linux/c.cpp' and `freebsd/c.cpp'

¿Alguna idea sobre cómo configurar automake respetar esta condición, incluso en el Makefile.in construir proccess?

esto funciona si los archivos tienen nombres diferentes, pero es código C ++ y yo estoy tratando de mantener los nombres de archivo el mismo que el nombre de la clase.

Gracias de antemano!

Answer 1

Se puede solicitar para los objetos que se construirá en sus respectivos subdirectorios con

AUTOMAKE_OPTIONS = subdir-objects

Answer 2

Otra opción, además de subdirectorios-objetos , es dar a cada sub-proyecto alguna costumbre por proyecto construir banderas. Al hacer esto, automake cambia su * .o reglas de denominación de anteponer el nombre del destino en el nombre del módulo. Por ejemplo, esto:

mylib_la_CXXFLAGS=$(AM_CXXFLAGS)
mylib_la_SOURCES=a.cpp b.cpp

se traducirá en los archivos de salida mylib_la-a.o y mylib_la-b.o, en lugar de a.o y B.O. De este modo se pueden tener dos proyectos diferentes con el mismo directorio de salida que cada uno tiene, por ejemplo, un archivo b.cpp, y no tener su conflicto salidas.

Tenga en cuenta que hice esto estableciendo las CXXFLAGS específicos del proyecto a los valores automake ya se iba a utilizar, AM_CXXFLAGS. Automake no es lo suficientemente inteligente como para detectar este truco y utilizar la más cortos * Los nombres .o. Si sucede que usted no necesita opciones de construcción por proyecto, por supuesto puede hacer que en lugar de este corte.

Hay una lista completa de variables automake que, cuando se encuentra en función de cada ejecutable, dan a este mismo efecto. Así, por ejemplo, tal vez un sub-proyecto necesita banderas de enlace especial ya, por lo que le dan algo como:

mylib_la_LDFLAGS=-lfoo

Esto le dará los prefijados * .o archivos al igual que el truco AM_CXXFLAGS hizo, sólo que ahora está "legítimamente" el uso de esta función, en lugar de engañar a automake para que lo hiciera.

Por cierto, es de estilo autoconf mal para cambiar cómo su programa se basa basa únicamente en el sistema operativo que está siendo construido para. Buen estilo autoconf es comprobar solamente para las características específicas de la plataforma, no plataformas enteras, porque cambian las plataformas. FreeBSD podría ser de cierta manera hoy en día, pero tal vez en la próxima versión va a copiar una característica de Linux que borraría la necesidad de que usted construya su programa de dos maneras diferentes. O, tal vez la característica que está utilizando hoy en día está en desuso, y será dado de baja en la siguiente versión.

Hay cuarenta años de sabiduría de programación Unix portátil en las autotools, saltamontes. Los "tal vez" que he dado anteriormente Tienes ocurrió en el pasado, y sin duda hacerlo de nuevo. Prueba de características individuales es la forma más ágil para hacer frente a las plataformas en constante cambio.

Usted puede obtener beneficios inesperados de este enfoque, también. Por ejemplo, tal vez su programa necesita dos características no portátiles para hacer su trabajo. Decir que en FreeBSD, estas son las características A y B, y en Linux, que son las características X e Y; A y X son mecanismos similares pero con diferentes interfaces, y el mismo para B y Y. podría ser que disponen de una proviene de los BSD originales, y está en Solaris porque tiene raíces BSD de SunOS en los años 80, y Solaris también tiene cuentan con Y desde su rediseño basado System V a principios de los 90. Mediante pruebas de estas características, el programa podría funcionar en Solaris, también, porque tiene las características de su programa necesita, pero no en la misma combinación que en FreeBSD y Linux.