autotoolsはマルチプラットフォームのメイクファイルを作成できます
https://stackoverflow.com/questions/324134
-
11-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
プラグインが[プライマリアプリケーションバージョン、サードパーティライブラリバージョン、32ビット対64ビット]のさまざまな組み合わせで動作するプラグインプロジェクトを数年間開発しています。 autotoolsを使用して、プラグインのすべてのバージョンをビルドする単一のmakefileを作成する（クリーンな）方法はありますか。
autotoolsのドキュメントをざっと読んでわかる限り、私が望むものに最も近い近似は、プロジェクトのN個の独立したコピーを持ち、それぞれが独自のメイクファイルを持つことです。 （a）コードの変更をすべての異なるコピーに継続的に伝播する必要があり、（b）プロジェクトを何度も複製するために多くの無駄なスペースがあるため、これはテストと開発に少し最適ではないようです。より良い方法はありますか？
編集：
しばらくの間、独自のソリューションを展開してきました。そこでは、さまざまなサードパーティのライブラリバージョンなどを追い出すための派手なメイクファイルといくつかのperlスクリプトがあります。他のビルドツールについては、エンドユーザーが非常に簡単にインストールできるようにしたいと思います。また、ツールは、さまざまなサードパーティのライブラリとヘッダーを大したトラブルなしで追い詰めるのに十分なスマートである必要があります。私は主にLinuxソリューションを探していますが、Windowsおよび/またはMacでも機能するソリューションはボーナスです。
他のヒント
質問が次の場合：
一部のマシンAでautotoolsを使用して、他のすべてのマシンで機能する単一のユニバーサルメイクファイルを作成できますか？
その答えは「いいえ」です。 autotoolsは、それをしようとするふりをしません。ターゲットマシンで実行可能なメイクファイルを作成する方法を決定するポータブルコードを含むように設計されています。
質問が次の場合：
autotoolsを使用して、32ビットと64ビットの問題は言うまでもなく、プラグインが動作するプライマリソフトウェアのさまざまなバージョン、およびさまざまなサードパーティライブラリで、さまざまなマシンで実行する必要があるソフトウェアを構成できますか？
答えは「はい」です。 autotoolsは、それができるように設計されています。さらに、Unix、Linux、MacOS X、BSDで動作します。
IBM Informixデータベースで動作するプログラムSQLCMD（10年以上前に同じ名前のMicrosoftプログラムより前のバージョン）があります。クライアントソフトウェアのバージョン（IBM Informix ESQL / C、IBM Informix ClientSDKまたはCSDKの一部）がインストールされていること、およびそれが32ビットか64ビットかを検出します。また、インストールされているソフトウェアのバージョンを検出し、その機能をサポート製品で利用可能なものに適合させます。約17年間にわたってリリースされたバージョンをサポートします。これは自動構成されています-Informix機能用と、他のいくつかのギズモ（高解像度のタイミング、/ dev / stdinの存在など）のためにいくつかのautoconfマクロを作成する必要がありました。しかし、それは実行可能です。
一方で、私はすべての顧客のマシンと環境に適合する単一のメイクファイルをリリースしようとはしません。賢明であるにはあまりにも多くの可能性があります。しかし、autotoolsは私（およびユーザー）の詳細を処理します。彼らがすることはすべて：
./configure
メイクファイルを編集する方法を見つけるよりも簡単です。 （ああ、最初の10年間、プログラムは手作業で構成されていました。かなり良い既定値が設定されていても、人々にとっては難しいことでした。それが自動構成に移行した理由です。インストールする人。）
Mr Foozはコメントしました：
間に何かが欲しい。私の場合、顧客は同じマシン上で同じベースアプリケーションの複数のバージョンとビットネスを使用します。 LinuxでWindowsバイナリをビルドするなどのクロスコンパイルについては心配していません。
32ビット版と64ビット版のプラグインの個別のビルドが必要ですか？ （私はそうだと思います-しかし、あなたは私を驚かせることができます。）だからあなたはユーザーが言うメカニズムを提供する必要があります
./configure --use-tppkg=/opt/tp/pkg32-1.0.3
（tppkgはサードパーティパッケージのコードであり、場所はユーザーが指定できます。）ただし、使いやすさを念頭に置いてください。ユーザーが提供するオプションが少ない 、よりいい;それに対して、インストール場所など、オプションである必要があるものをハードコーディングしないでください。必ずデフォルトの場所を見てください-それは良いことです。そして、あなたが見つけたもののほんの少しをデフォルトにします。たぶん、32ビット版と64ビット版の両方を見つけたら、両方をビルドする必要があります。ただし、慎重に構築する必要があります。 ＆quot; TP-Packageのチェック... ''をいつでもエコーできます。見つけたものと見つけた場所を示します。その後、インストーラーはオプションを変更できます。オプションが何であるかを「 ./ configure --help 」に文書化してください。これは標準的なautotoolsのプラクティスです。
ただし、インタラクティブな操作は行わないでください。 configureスクリプトが実行され、実行内容が報告されます。 Perlの Configure スクリプト（大文字に注意してください-完全に独立した自動構成システムです）は、残された数少ない集中的な構成システムの1つです（そして、それはおそらくその遺産のためです。 、ほとんどの場合非対話型です）。そのようなシステム
試しましたが機能しません！そこで、現在 SCons を使用しています。
編集： SConsが好きな理由の小さな例：
env.ParseConfig('pkg-config --cflags --libs glib-2.0')
このコード行を使用して、GLibをコンパイル環境に追加します（ env ）。また、ユーザーガイドを忘れないでくださいこれは、SConsを学ぶのに最適です（Pythonを知っている必要はありません！）。エンドユーザーは、 PyInstaller またはそのようなものでSConsを試すことができます。
そして make と比較して、あなたはPythonを使用しているので、完全なプログラミング言語です！これを念頭に置いて、すべてを（ほぼ）行うことができます。
複数のビルドディレクトリを持つ単一のプロジェクトを使用することを検討したことがありますか？ automakeプロジェクトが適切な方法で実装されている場合（つまり、gccとは異なります）
以下が可能です：
mkdir build1 build2 build3
cd build1
../configure $(YOUR_OPTIONS)
cd build2
../configure $(YOUR_OPTIONS2)
[...]
インクルードディレクトリやコンパイラーなどのさまざまな構成パラメーターを渡すことができます（つまり、コンパイラー間で）。
これを実行することで、1回のmake呼び出しでこれを実行することもできます
make -C build1 -C build2 -C build3
