5

FreeBSD ホストでコンパイルするように適応させている C++ autoconf マネージド プロジェクトがあります。元のシステムは Linux だったので、AM_CONDITIONAL を 1 つ作成して、ビルドしているホストを識別し、コードをシステム固有のファイルに分けました。

configure.ac

AC_CANONICAL_HOST
AM_CONDITIONAL([IS_FREEBSD],false)
ケース $host in
        *自由*）    
            AC_DEFINE([IS_FREEBSD],[1],[FreeBSD ホスト])
            AM_CONDITIONAL([IS_FREEBSD],真)
            BP_ADD_LDFLAG([-L/usr/local/lib])
                ;;
エサック

Makefile.am

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

IS_FREEBSD の場合
    mylib_la_SOURCES+=freebsd/c.cpp
そうしないと
    mylib_la_SOURCES+=linux/c.cpp
終了

automake を実行すると、次のようなメッセージで失敗します。

Makefile.am: `linux/c.cpp' と `freebsd/c.cpp' によって作成されたオブジェクト `c.lo'

Makefile.in ビルド プロセスでもこの条件を尊重するように automake を構成する方法についてのアイデアはありますか?

ファイルの名前が異なる場合、これは機能しますが、それは C++ コードであり、ファイル名をクラス名と同じに保とうとしています。

前もって感謝します！

4

2 に答える 2

11

オブジェクトをそれぞれのサブディレクトリに構築するように要求できます。

AUTOMAKE_OPTIONS = subdir-objects
于 2009-05-28T07:37:38.570 に答える
7

subdir-objects以外の別のオプションは、各サブプロジェクトにプロジェクトごとのカスタム ビルド フラグを与えることです。これを行うと、automake はその *.o 命名規則を変更して、ターゲット名をモジュール名の先頭に追加します。たとえば、次のようになります。

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

ao と bo ではなく、出力ファイル mylib_la-ao と mylib_la-bo が生成されます。したがって、同じ出力ディレクトリを持つ 2 つの異なるプロジェクトを作成し、それぞれにたとえば b.cpp ファイルを含めることができ、それらの出力が競合することはありません。

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

実行可能ファイルごとに設定すると、これと同じ効果が得られる automake 変数の完全なリストがあります。たとえば、1 つのサブプロジェクトですでに特別なリンク フラグが必要な場合は、次のように指定します。

mylib_la_LDFLAGS=-lfoo

これにより、AM_CXXFLAGS トリックと同じようにプレフィックス付きの *.o ファイルが得られますが、automake をだまして実行させるのではなく、この機能を「合法的に」使用しているだけです。

ところで、ビルド対象の OS だけに基づいてプログラムのビルド方法を変更するのは、autoconf スタイルとしては良くありません。プラットフォームは変化するため、autoconf の適切なスタイルは、プラットフォーム全体ではなく、特定のプラットフォーム機能のみをチェックすることです。FreeBSD は現在、特定の方法である可能性がありますが、次のリリースでは、プログラムを 2 つの異なる方法で構築する必要がなくなる機能を Linux からコピーする可能性があります。または、現在使用している機能が廃止され、次のバージョンで削除される可能性があります。

autotools、grasshopper には、40 年にわたる移植可能な Unix プログラミングの知恵があります。私が上で述べた「たぶん」は過去に起こったことであり、間違いなく再びそうなるでしょう。個々の機能をテストすることは、絶え間なく変化するプラットフォームに対処するための最も迅速な方法です。

このアプローチからも、予期しないボーナスを得ることができます。例えば、あなたのプログラムは、その作業を行うために 2 つの移植性のない機能を必要とするかもしれません。FreeBSD では、これらは A および B 機能であり、Linux では X および Y 機能であるとします。A と X は同様のメカニズムですが、インターフェースが異なり、B と Y も同じです。機能 A はオリジナルの BSD から来ており、80 年代の SunOS の BSD ルートを持ち、Solaris にもあるため、Solaris にある可能性があります。 90 年代初頭の System V ベースの再設計による機能 Y。これらの機能をテストすることで、Solaris でもプログラムを実行できます。これは、FreeBSD や Linux と同じ組み合わせではなく、プログラムが必要とする機能を備えているためです。

于 2009-08-10T14:16:06.460 に答える