Automakeのと同じ名前を持つファイル

StackOverflow https://stackoverflow.com/questions/917948

  •  06-09-2019
  •  | 
  •  

質問

私はFreeBSDのホスト上でコンパイルするために適応していますC ++のautoconf管理プロジェクトをしました。 元のシステムは、Linuxので、私は建物だホストを区別し、システム固有のファイルにコードを分離するために、1 AM_CONDITIONALとした。

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

私はautomakeを実行すると、それはこの種のメッセージで失敗します：

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

proccessを構築してもMakefile.inでこの条件を尊重するためにはautomakeを設定する方法上の任意のアイデア？

ファイルはdiferent名前を持っている場合、私はこの作品が、それは、C ++のコードだと、私はクラス名と同じファイル名を維持しようとしています。

事前に感謝します！

役に立ちましたか？

解決

は、

と、それぞれのサブディレクトリに建設されるオブジェクトのために要求することができます 
AUTOMAKE_OPTIONS = subdir-objects

他のヒント

別のオプションは、のサブディレクトリ・オブジェクトのほかに、フラグを構築し、各サブプロジェクトにプロジェクトごとのいくつかのカスタムを与えることです。これを行うと、Automakeはモジュール名にターゲット名を付加する命名規則の.oその*を変更します。たとえば、この：

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

むしろa.oとb.o.よりも、出力ファイルmylib_la-a.oとmylib_la-b.oになりますしたがって、あなたは、それぞれが、たとえば、b.cppファイルを持って同じ出力ディレクトリを持つ2つの異なるプロジェクトを持って、その出力の競合を持っていないことができます。

私は値のautomakeにプロジェクト固有のCXXFLAGSを設定することによってこれをしなかった通知はすでに、AM_CXXFLAGSを使用するつもりでした。 Automakeはこのトリックを検出し、短い* .oの名前を使用するのに十分にスマートではありません。それはあなたがプロジェクトごとのビルド・オプションが必要ですというような場合、あなたはもちろんその代わりに、このハックを行うことができます。

に設定し、automakeの変数のリスト全体のrel="noreferrer"> 

mylib_la_LDFLAGS=-lfoo

このはAM_CXXFLAGSトリックは今だけ、あなたが「合法的に」この機能を使用して、代わりにそれをやってにはautomakeをだましている、やったと。

あなたの接頭辞* .oファイルを提供します

ところで、それはあなたのプログラムは、単にそれがために構築されていますOSに基づいてビルド方法を変更することが悪いのautoconfスタイルです。プラットフォームが変わるので、良いautoconfのスタイルは、唯一の特定のプラットフォームの機能ではなく、全体のプラットフォームをチェックすることです。 FreeBSDは今日特定の方法かもしれませんが、おそらく次のリリースでは、それはあなたがあなたのプログラム二つの異なる方法を構築するための必要性を消去しますLinuxからの機能をコピーします。または、多分あなたが今日使用している機能は廃止され、そして次のバージョンで削除されます。

autotoolsの携帯Unixのプログラミング知恵、バッタの40年があります。私はのHAVE の上に与えてくれた「maybesは、」過去に起こった、と確かに再びそれを行うだろう。個々の機能をテストすることは常に変化するプラットフォームに対処するnimblest方法です。

あなたも、このアプローチからの予想外のボーナスを得ることができます。たとえば、多分あなたのプログラムは、その作業を行うために、2つの移植性の機能を必要とします。 FreeBSD上でそれを言って、これらはAとBの特徴であり、Linux上で、彼らはXとYの特徴です。 A及びXは、同様のメカニズムであるが、BおよびYに対して異なるインターフェース、および同じではAは、元のBSDから来て、それは80年代ののSunOSからBSD根を有し、およびSolarisも有しているため、Solarisであること特徴とすることができます90年代初頭におけるそれのSystem Vベースの再設計から機能Y。それはあなたのプログラムは、FreeBSDやLinux上としてだけでなく、同じ組み合わせで、必要な機能を持っているので、これらの機能をテストすることで、あなたのプログラムは、あまりにも、Solaris上で実行することができます。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top