あなたの質問が次の場合:
一部のマシン A で autotools を使用して、他のすべてのマシンで動作する単一のユニバーサル makefile を作成できますか?
答えは「いいえ」です。自動ツールは、それをやろうとしているふりさえしません。これらは、ターゲット マシンで実行可能なメイクファイルを作成する方法を決定する移植可能なコードを含むように設計されています。
あなたの質問が次の場合:
autotools を使用して、32 ビットと 64 ビットの問題は言うまでもなく、プラグインが動作する主要なソフトウェアの異なるバージョンとさまざまなサードパーティ ライブラリを使用して、異なるマシンで実行する必要があるソフトウェアを構成できますか?
答えは「はい」です。autotools は、それができるように設計されています。さらに、Unix、Linux、MacOS X、BSD で動作します。
私は、IBM Informix データベースで動作する SQLCMD (同名の Microsoft プログラムよりも 10 年以上前のプログラム) というプログラムを持っています。インストールされているクライアント ソフトウェア (IBM Informix ESQL/C と呼ばれ、IBM Informix ClientSDK または CSDK の一部) のバージョンと、それが 32 ビットか 64 ビットかを検出します。また、インストールされているソフトウェアのバージョンを検出し、その機能をサポートする製品で利用できるものに適応させます。約17年間にリリースされたバージョンに対応しています。これは自動構成されています。Informix 機能と他のいくつかのギズモ (高解像度タイミング、/dev/stdin の存在など) のために、いくつかの autoconf マクロを作成する必要がありました。しかし、それは実行可能です。
一方で、すべての顧客のマシンと環境に適合する単一の makefile をリリースしようとはしません。それが賢明であるには、あまりにも多くの可能性があります。しかし、autotools は私 (および私のユーザー) のために詳細を処理します。彼らがすることはすべて:
./configure
これは、makefile を編集する方法を考えるよりも簡単です。(ああ、最初の 10 年間、プログラムは手動で設定されていました。かなり良いデフォルト設定があったにもかかわらず、人々がそれを行うのは困難でした。それが、自動設定に移行した理由です。人がインストールします。)
フーズ氏は次のようにコメントしています。
間に何かが欲しい。私の場合、顧客は同じマシン上で同じベース アプリケーションの複数のバージョンとビット数を使用します。Linux で Windows バイナリをビルドするようなクロスコンパイルについては心配していません。
32 ビット版と 64 ビット版のプラグインを個別にビルドする必要がありますか? （私はイエスだと思いますが、驚かれるかもしれません。）したがって、ユーザーが言うメカニズムを提供する必要があります。
./configure --use-tppkg=/opt/tp/pkg32-1.0.3
(ここで、tppkg はサードパーティ パッケージのコードであり、場所はユーザーが指定できます。) ただし、使いやすさに注意してください。ユーザーが提供する必要のあるオプションが少ないほど良いです。それに対して、インストール場所など、オプションであるべきものをハードコーディングしないでください。必ずデフォルトの場所を見てください - それは良いことです。そして、あなたが見つけたものの辛さをデフォルトにします。32 ビット バージョンと 64 ビット バージョンの両方が見つかった場合は、両方をビルドする必要がありますが、慎重に作成する必要があります。いつでも「TP-Package をチェックしています...」とエコーして、見つけたものと見つけた場所を示すことができます。その後、インストーラーはオプションを変更できます。./configure --helpオプションが何であるかを ' ' に文書化してください。これは autotools の標準的な方法です。
ただし、インタラクティブなことはしないでください。configure スクリプトが実行され、その動作が報告されます。PerlConfigureスクリプト (大文字に注意してください。これは完全に独立した自動構成システムです) は、残された数少ない集中的に対話型の構成システムの 1 つです (そして、それはおそらく主にその遺産によるものです。相互の作用）。このようなシステムは、非対話型のシステムよりも構成が面倒です。
クロスコンパイルは大変です。私はそれをする必要はありませんでした。
また、フーズ氏は次のようにコメントしています。
追加コメントありがとうございます。私は次のようなものを探しています:
./configure --use-tppkg=/opt/tp/pkg32-1.0.3 --use-tppkg=/opt/tp/pkg64-1.1.2
現在のプラットフォーム用の 1 つの makefile で 32 ビットと 64 ビットの両方のターゲットを作成します。
まあ、それはできると確信しています。完全な再構築を間に挟んで 2 つの個別の構成を実行する場合と比較して、実行する価値があるかどうかはわかりません。おそらく使用したいでしょう：
./configure --use-tppkg32=/opt/tp/pkg32-1.0.3 --use-tppkg64=/opt/tp/pkg64-1.1.2
これは、2 つの別個のディレクトリーを示します。ビルドをどのように行うかを決定する必要がありますが、オブジェクト ファイルの個別のセットを格納するために、obj-32' ' と ' 'などの 2 つのサブディレクトリが必要になると思われます。obj-64また、次の行に沿ってメイクファイルを配置します。
FLAGS_32 = ...32-bit compiler options...
FLAGS_64 = ...64-bit compiler options...
TPPKG32DIR = @TPPKG32DIR@
TPPKG64DIR = @TPPKG64DIR@
OBJ32DIR = obj-32
OBJ64DIR = obj-64
BUILD_32 = @BUILD_32@
BUILD_64 = @BUILD_64@
TPPKGDIR =
OBJDIR =
FLAGS =
all: ${BUILD_32} ${BUILD_64}
build_32:
${MAKE} TPPKGDIR=${TPPKG32DIR} OBJDIR=${OBJ32DIR} FLAGS=${FLAGS_32} build
build_64:
${MAKE} TPPKGDIR=${TPPKG64DIR} OBJDIR=${OBJ64DIR} FLAGS=${FLAGS_64} build
build: ${OBJDIR}/plugin.so
これは、プラグインが共有オブジェクトであることを前提としています。ここでの考え方は、autotool がサード パーティ パッケージの 32 ビットまたは 64 ビットのインストールを検出し、置換を行うというものです。BUILD_32 マクロは、32 ビット パッケージが必要な場合は build_32 に設定され、それ以外の場合は空のままになります。BUILD_64 マクロも同様に処理されます。
ユーザーが ' make all' を実行すると、最初に build_32 ターゲットがビルドされ、次に build_64 ターゲットがビルドされます。build_32 ターゲットをビルドするには、再実行makeして 32 ビット ビルド用のフラグを構成します。make同様に、build_64 ターゲットをビルドするには、64 ビット ビルドのフラグを再実行して構成します。32 ビット ビルドと 64 ビット ビルドの影響を受けるすべてのフラグが の再帰呼び出しに設定されているmakeこと、およびオブジェクトとライブラリをビルドするための規則が慎重に記述されていることが重要です。たとえば、ソースをオブジェクトにコンパイルするための規則は、オブジェクト ファイルを正しいオブジェクト ディレクトリに配置するように注意してください。たとえば、GCC を使用する場合は、(.c.oルールで) 次のように指定します。
${CC} ${CFLAGS} -o ${OBJDIR}/$*.o -c $*.c
マクロ CFLAGS には、ビットを処理する ${FLAGS} 値が含まれます (たとえば、FLAGS_32 = -m32FLAGS_64 = -m64 , and so when building the 32-bit version,FLAGS = -m32 would be included in theCFLAGS` マクロ.
autotools の残りの問題は、32 ビットと 64 ビットのフラグを決定する方法を解決することです。最悪の場合は、自分でマクロを作成する必要があります。ただし、autotoolsスイートの標準機能を使用して実行できると（調査していなくても）期待できます。
慎重に (容赦なく) 対称的な makefile を自分で作成しない限り、確実に動作することはありません。