Automake et fichiers avec le même nom

Question

J'ai un projet géré C ++ autoconf que je me adapte à compiler sur les hôtes FreeBSD. Le système original était Linux, donc je fait un AM_CONDITIONAL pour distinguer l'hôte Je construis et séparer le code dans le système de fichiers spécifiques.

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

Quand je lance automake il échoue avec ce genre de message:

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

Toutes les idées sur la façon de configurer automake pour respecter cette condition même dans le Makefile.in construire proccess?

I cela fonctionne si les fichiers ont des noms diférents, mais il est c ++ code et je suis en train de garder les noms de fichiers le même que le nom de la classe.

Merci d'avance!

Answer 1

Vous pouvez demander pour les objets à construire dans leurs sous-répertoires respectifs avec

AUTOMAKE_OPTIONS = subdir-objects

Answer 2

Une autre option, en plus de objets subdir-, est de donner à chaque sous-projet d'une coutume de construire des drapeaux par projet. Lorsque vous faites cela, automake change * .o règles de nommage pour préfixer le nom cible sur le nom du module. Par exemple, ceci:

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

entrainera dans les fichiers de sortie mylib_la-a.o et mylib_la-b.o, plutôt que a.o et b.o. Ainsi, vous pouvez avoir deux projets différents avec le même répertoire de sortie qui ont chacun, par exemple, un fichier b.cpp, et ne pas avoir leur conflit sorties.

Notez que je l'ai fait en définissant les CXXFLAGS spécifiques au projet aux valeurs automake allait déjà utiliser, AM_CXXFLAGS. Automake est pas assez intelligent pour détecter cette astuce et utiliser le plus court * Les noms .o. S'il arrive que vous avez besoin par projet de construction d'options, vous pouvez bien sûr faire au lieu de ce hack.

Il y a un liste complète des variables automake qui, lorsqu'il est réglé sur une base par exécutable, donnent à ce même effet. Ainsi, par exemple, peut-être un sous-projet a besoin d'indicateurs de lien spécial déjà, vous donner quelque chose comme:

mylib_la_LDFLAGS=-lfoo

Cela vous donnera les préfixées * .o tout comme l'affaire AM_CXXFLAGS a fait, maintenant que vous êtes « légitimement » utiliser cette fonction, au lieu de duper automake en faire.

Par ailleurs, il est mauvais style autoconf pour changer la façon dont votre programme builds basé uniquement sur le système d'exploitation, il est en cours de construction pour. Un bon style autoconf est de vérifier que pour les fonctionnalités de plate-forme spécifique, les plates-formes non entières, parce que le changement des plates-formes. FreeBSD est peut-être d'une certaine façon aujourd'hui, mais peut-être dans la prochaine version, il copiera une fonction de Linux qui effacerait la nécessité pour vous de construire votre programme de deux façons différentes. Ou, peut-être la fonction que vous utilisez aujourd'hui est dépréciée et sera supprimé dans la prochaine version.

Il y a quarante ans de sagesse de programmation portable Unix dans les autotools, sauterelle. Les « maybes » J'ai donné ci-dessus Vous est arrivé dans le passé, et feront certainement à nouveau. Test de caractéristiques individuelles est la façon de faire face agile en constante évolution avec les plates-formes.

Vous pouvez obtenir des bonus inattendus de cette approche, aussi. Par exemple, peut-être votre programme a besoin de deux fonctionnalités nonportable pour faire son travail. Dire que sur FreeBSD, ce sont les caractéristiques A et B, et sous Linux, ils sont les caractéristiques X et Y; A et X sont des mécanismes similaires, mais avec des interfaces différentes, et même pour B et Y. Il pourrait être cette caractéristique A provient des BSDs d'origine, et est Solaris, car il a des racines BSD de SunOS dans les années 80, et Solaris a également Y en vedette à partir de son système à base de refonte V au début des années 90. En testant ces fonctionnalités, votre programme pourrait fonctionner sur Solaris, aussi, car il a les caractéristiques de votre programme a besoin, tout simplement pas dans la même combinaison que sur FreeBSD et Linux.