Automake e arquivos com o mesmo nome

Question

Eu tenho projeto autoconf conseguiu um C ++ que estou adaptando para compilar em hosts do FreeBSD. O sistema original Linux, então eu fiz um AM_CONDITIONAL para distinguir o anfitrião Estou construindo e separar o código em arquivos específicos do sistema.

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

Quando eu executo o automake ele falha com este tipo de mensagem:

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

Algumas ideias sobre como configurar automake a respeitar este mesmo condicional na construção proccess Makefile.in?

Eu Isso funciona se os arquivos têm nomes diferentes, mas o código-lo de c ++ e estou tentando manter os nomes de arquivos o mesmo que o nome da classe.

Agradecemos antecipadamente!

Answer 1

Você poderia pedir para os objetos a ser construído em seus respectivos subdiretórios com

AUTOMAKE_OPTIONS = subdir-objects

Answer 2

Outra opção, além de subdir-objetos , é dar a cada sub-projeto alguns personalizados por projeto bandeiras de construção. Quando você fizer isso, automake muda seu * .o regras de nomeação para preceder o nome de destino para o nome do módulo. Por exemplo, esta:

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

resultará na saída de arquivos mylib_la-a.o e mylib_la-b.o, ao invés de a.o e B.O. Assim, você pode ter dois projectos diferentes com o mesmo diretório de saída que cada um tem, digamos, um arquivo b.cpp, e não têm o seu saídas de conflitos.

Observe que eu fiz isso, definindo os CXXFLAGS específicos do projeto para o automake valores já estava indo para uso, AM_CXXFLAGS. Automake não é inteligente o suficiente para detectar este truque e usar o mais curtas * nomes .o. Se acontece que você precisa de opções de construção por projeto, você pode, naturalmente, fazer isso em vez de este hack.

Há um toda lista de automake variáveis ??que, quando definido em uma base por executável, dão a este mesmo efeito. Assim, por exemplo, talvez um sub-projeto precisa sinalizadores especiais link já, para que dar-lhe algo como:

mylib_la_LDFLAGS=-lfoo

Isto lhe dará os arquivos * .o prefixados assim como o truque AM_CXXFLAGS fez, só que agora você é "legitimamente" usando esse recurso, em vez de enganar automake em fazê-lo.

A propósito, é de estilo autoconf mal a mudança como seu programa constrói com base unicamente no sistema operacional que está sendo construído. Bom estilo autoconf é verificar apenas para recursos da plataforma específicas, não plataformas inteiras, porque a mudança plataformas. FreeBSD pode ser uma certa maneira hoje, mas talvez no próximo lançamento que vai copiar um recurso de Linux que iria apagar a necessidade para você construir seu programa de duas formas diferentes. Ou, talvez o recurso que você está usando hoje é obsoleto e será descartado na próxima versão.

Há quarenta anos de sabedoria portátil de programação Unix nas autotools, gafanhoto. Os "talvez" que eu dei acima Have aconteceu no passado, e certamente vai fazê-lo novamente. Testando características individuais é o caminho nimblest para lidar com plataformas em constante mudança.

Você pode obter bônus inesperado com esta abordagem, também. Por exemplo, talvez o seu programa precisa de duas características nonportable para fazer seu trabalho. Dizer que no FreeBSD, estes são os A e B possui, e no Linux, eles são o X e Y apresenta; A e X são mecanismos semelhantes, mas com diferentes interfaces, e o mesmo para B e Y. Pode ser que apresentam uma vem da BSD originais, e é em Solaris porque tem raízes BSD de SunOS nos anos 80, e Solaris também possui o recurso de Y a partir dele de redesenho baseado System V no início dos anos 90. Ao testar para estas funções, o programa pode ser executado em Solaris, também, porque tem as características suas necessidades de programa, não apenas na mesma combinação como no FreeBSD e Linux.