Automake e file con lo stesso nome

Question

Ho un progetto C ++ autoconf gestito che sto adattando a compilare su host FreeBSD. Il sistema originale era di Linux così ho fatto uno AM_CONDITIONAL distinguere l'host sto costruendo e separare il codice nel sistema di file specifici.

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 eseguo automake fallisce con questo tipo di messaggio:

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

Tutte le idee su come configurare automake a rispettare questo condizionale anche in Makefile.in costruire proccess?

I questo funziona se i file hanno nomi diferent, ma è codice C ++ e sto cercando di mantenere i nomi dei file lo stesso nome della classe.

Grazie in anticipo!

Answer 1

Si potrebbe chiedere per gli oggetti da costruire nei rispettivi sottodirectory con

AUTOMAKE_OPTIONS = subdir-objects

Answer 2

Un'altra opzione, oltre a subdir-oggetti , è quello di dare ad ogni sotto-progetto un po 'su misura per ogni singolo progetto costruire bandiere. Quando si esegue questa operazione, automake cambia * .o regole di denominazione anteporre il nome di destinazione sul nome del modulo. Ad esempio, questo:

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

si tradurrà in file di output mylib_la-A. Ó e mylib_la-b.o, piuttosto che A. Ó e b.o. Così si può avere due diversi progetti con la stessa directory di output che ogni hanno, per esempio, un file b.cpp, e non hanno il loro conflitto uscite.

Si noti che ho fatto questo impostando le CXXFLAGS specifici del progetto ai valori automake era già intenzione di usare, AM_CXXFLAGS. Automake non è abbastanza intelligente per rilevare questo trucco e utilizzare * nomi .o il più brevi. Se accade che si ha bisogno per-progetto di opzioni di compilazione, si può ovviamente fare che invece di questo hack.

C'è un intera lista di variabili automake che, se impostato su una base per-eseguibile, danno lo stesso effetto. Così, per esempio, forse un sub-progetto ha bisogno di bandiere di collegamento speciali già, in modo da dare qualcosa di simile:

mylib_la_LDFLAGS=-lfoo

Questo vi darà i * .o file prefissati così come il trucco AM_CXXFLAGS ha fatto, solo ora si è "legittimamente" utilizzare questa funzione, invece di ingannare automake nel farlo.

Tra l'altro, è un cattivo stile autoconf per modificare la modalità programma si basa basata esclusivamente sul sistema operativo è in costruzione per. Buon stile autoconf è quello di verificare solo per specifiche caratteristiche della piattaforma, non piattaforme intere, perché le piattaforme cambiano. FreeBSD potrebbe essere in un certo modo oggi, ma forse nella prossima release sarà copiare una feature da Linux che cancella la necessità per voi per costruire il vostro programma di due modi diversi. O, forse la caratteristica che si sta utilizzando oggi è obsoleto e verrà abbandonato nella prossima versione.

C'è quarant'anni di portatile saggezza programmazione Unix negli autotools, cavalletta. Il "forse" Ho dato sopra sono è accaduto in passato, e che certamente farlo di nuovo. Test caratteristiche individuali è il modo più agile per far fronte con le piattaforme in continua evoluzione.

È possibile ottenere bonus inaspettato di questo approccio, anche. Per esempio, forse il programma ha bisogno di due caratteristiche non portabili a fare il suo lavoro. Dire che su FreeBSD, queste sono le caratteristiche A e B, e su Linux, sono le caratteristiche X e Y; A e X sono meccanismi simili ma con diverse interfacce, e lo stesso per B e Y. potrebbe essere che caratteristica Un proviene dalle BSD originali, ed è in Solaris perché ha radici BSD da SunOS negli anni '80, e Solaris ha anche caratterizzato da Y è System V riprogettazione base nei primi anni '90. Testando per queste caratteristiche, il programma potrebbe girare su Solaris, anche, perché ha le caratteristiche del programma ha bisogno, solo che non la stessa combinazione come su FreeBSD e Linux.