2

C/C++ に関する私の基本的な問題は、ライブラリのコンパイルの領域にあります。たとえば、ソフトウェア A はライブラリ Z を使用するため、ソフトウェア A をコンパイルしてその後使用および/または開発する前に、ライブラリ Z をコンパイルする必要があります。

多くの場合、プロジェクトを構成してから make + make install を呼び出すという概念があります。たとえば、コマンド ラインを開いて次のように入力します。

./configure
make
make install

./configureプロジェクトの最上位ディレクトリに配置されるシェル スクリプトです。すべての依存関係がシステムに存在するかどうかを確認し、これらの依存関係へのパスを保存すると思います。後で、make はこの収集された情報を使用して、それぞれのインクルード パスとライブラリの場所 (.so/.a ファイルの場所など) をコンパイラに提供できます。

makeソースファイルを正しい順序でコンパイルおよびリンクする責任があります（I-dont-knowによって生成され、XYZ形式のmakefileで指定されているとおり）。もちろん、それ自体をコンパイル/リンクするのではなく、実際のコンパイラとリンカーを呼び出して作業を行います。

make install結果のバイナリ ファイルを取得し、システム内のどこかに配置します (たとえば、プロジェクトがライブラリの場合は /usr/lib、実行可能ファイルの場合は /usr/bin )。手元のプロジェクトがライブラリの場合、おそらくライブラリのヘッダー ファイルも取得し、システムのどこかにインストールします。

これは比較的複雑なプロセスです。このタイプのコンパイル プロセスを表すために CMI を使用しましょう (CMI = configure-make-install)。また、CMI の概念は、私が知る限り、Linux の世界に固有のものです。たとえば、./configure の実行に使用できるシェルがないなどの理由で、Windows ではそのようには機能しません。make は gcc/g++ に限定されている可能性もありますが、そうなのかどうかはわかりません。

最も重要なことは、私はそれをどこで調べればよいかさえ知りません. また、CMI の概念が異なるバージョンのライブラリの同時インストールをサポートしているかどうかも調べたいと思います。あなたがソフトウェア B とソフトウェア C の開発者であるとします。ソフトウェア B と C はどちらもライブラリ Y に依存していますが、何らかの理由で、B には Y 1.0.x が必要であり、C には 1.1.x が必要です。make install がライブラリのヘッダー ファイルをシステムのどこかに配置した場合、衝突は発生しませんか? 繰り返しますが、私は自分自身に尋ねます。どこでそれを調べることができますか?

ライブラリの例について説明しましょう: libzip。ホームページには、サポートまたは推奨されるコンパイラまたはプラットフォームは記載されていません。今、どのように進めますか？

興味深いことに、このページでは、MySQL Workbench が libzip を使用していると主張しています。MySQL Workbench も Windows 用に提供されているので、libzip は Windows でコンパイルできると思います。

また、libzip にはCMakeLists.txt と構成スクリプトが同梱されていることもわかりました。おそらくpkg-configツール用のlibzip.pc.in CMake テンプレートもあります。Makefile.am (それが何であれ) と、別の CMake テンプレートと思われる Makefile.in もあります。最後になりましたが、フォルダー m4 と .m4 ファイル (m4 フォルダー内とプロジェクトのルート フォルダーの両方) に気付きました。ただし、cmake-config.h.in、cmake-zipconf.h.in を忘れないでください。

そのため、libzip をコンパイルする場合は、次の代替手段を検討する必要があります。

  • CMI の概念を使用する
    • Windowsには適用されません（そうですか？）
  • 一種のメタ ビルド システムである CMake を使用する
    • 次に、どのコンパイラ/IDE CMake を生成するかを決定する必要があります: gcc? MSVC? Mingw または QTSDK/MingW? （違いはともかく）
  • それが何であれ、M4を使用するかもしれません

M4 は GNU autoconf に関連しているようです。上記のリストに追加することもできると思います。

(補足: これまでのところ、CMake + Visual Studio 2010 の組み合わせを使用して libzip をコンパイルしようとしました。現在、あらゆる種類のコンパイル エラーを修正しています。)

これは私の中心的な観察です：

libzip は単純なライブラリです。ほんの一部のzipのもの。しかし、コンパイルには非常に多くのツールが必要なため、上級プログラマーにとっても非常に困難な作業です。

また、これらのツールのほとんどのドキュメントが不足しています (そうでなければ、答えがどこにあるのかわからず、なぜこれらすべての質問があるのでしょうか?)。言うまでもなく、ほとんどのツールは、バグのある CMake FindPackage-scripts sighなどを修正するためにリバース エンジニアリングに何時間も費やさないと機能しません。

私はそのようにWEEKSを続けることができました。多数のコンパイルの概念、それらすべてが互いにどのように関連しているか、どのプラットフォームとコンパイラがうまく機能するかなどについて、私は迷っています。

別の例: RetroShare。Windows のコンパイル プロセスは文書化されていますが、コンパイルを完了するのは非常に困難です。Windows で RetroShare をコンパイルするには、QtSDK/MingW、Cygwin、および MingW/MSYS が必要であり、それらはすべて異なる部分/依存関係にあることを考慮してください。これらのツールはどのように連携しますか?

私は完全に途方に暮れており、これらすべてのツール/ツールチェーン/コンパイラ/プラットフォームを考慮して、この種の問題にどのように対処し、深刻な損傷から心をどのように保護するかを教えてほしい.

あなたたちは非常に賢いですか、それとも私は非常に愚かですか? なぜこれは非常に複雑なのですか (またはそうでないのですか)?

4

2 に答える 2

2

「私はそのようにWEEKSを続けることができました。」

あなたは少し混乱しているように聞こえます。いくつかの具体的なポイントについて説明します。

「configure-make-install」プロセスmakeでは、より汎用的なツールである を特別に使用します。つまり、make と makefile は別の方法で使用できます。心に留めておきます。

「makeは、ソースファイルを正しい順序でコンパイルおよびリンクする責任があります（makefileで指定されているとおりです。これは、I-dont-knowによって生成され、形式がXYZです）。」

遅かれ早かれ、メイクファイルを自分で書く方法を学ばなければならないことはほぼ確実です。Make はビルド システムであり、C/C++ プログラマにとって非常に便利でほぼ必須のツールです。IDE を使用している場合は、既に makefile が作成されている可能性があります。以下は、小さなプロジェクト用に手動で作成された makefile の例です。

wx = `wx-config --cxxflags --libs`

test1: main.cpp main.h window.o
        g++ -Wall -g main.cpp window.o -o test1 $(wx)

window.o: window.cpp window.h
        g++ -Wall -g -c window.cpp -o window.o $(wx)

最初の行は、変数とリンカーのいくつかのフラグを定義します。これはその後 2 回使用されます。コマンド ラインで gcc を使用する場合、次の 2 ビットはおなじみのはずです。このプロジェクトを なしmakeでビルドするには、最初に window.o をコンパイルしg++ ...、次にtest1. メイクファイルが整ったら、実行するだけですmake。プロジェクトにさらにいくつかのオブジェクト (.o) ファイルを追加すると、非常に便利に思えてきます。また、 1 つの makefile に異なる「ターゲット」を書き込むこともできます。さまざまな make チュートリアルと、GNU バージョンの公式ドキュメントがあります。

http://www.gnu.org/software/make/manual/make.html

理解するのは難しくありません。

「make install は結果のバイナリ ファイルを取得し、システム内のどこかに配置します」

make installconfigure-make-install コンテキストで使用される makefile でそれを行うために慣習的に定義されたターゲットです。上記のmakefileにそのようなものを追加できます：

install: test1
    cp test1 /usr/local/bin/

コロンの後のターゲットと同じ行にあるものはすべて前提条件です。ビルド ツリーに存在する必要があるファイル (または実行する必要がある別のターゲット ディレクティブ) を参照します。ファイルが存在しない場合 (またはビルド後に前提条件の一部が変更された場合) で、同じ名前のターゲットがある場合 (この場合は、test1以前の前提条件も参照してください)、そのターゲット ディレクティブが実行されます。最初。

「また、CMI の概念は、私が知る限り、Linux の世界に固有のものです。」

いいえ、しかしそれは Windows の世界とは少し異質です。これは、configure スクリプトと対応する makefile を生成するために使用できるautotoolsに関連して言及されることがあります。mingwがインストールされている場合、Windows で CMI パッケージを使用できることに注意してください。

「一種のメタビルドシステムであるCMakeを使用してください」

CMake は基本的に make と同じもので、異なるだけです。 makemakefile で明示的に呼び出された場合にのみ gcc を使用します。makefile は、コンパイラの実行など、シェル スクリプトが実行できるほぼすべてのことを実行するように記述できます。CMake は、より移植性が高く、プラットフォームに依存せず、おそらくユーザー フレンドリーであることを目指しています。その方が好きな人もいます。

「make install がライブラリのヘッダー ファイルをシステムのどこかに配置した場合、衝突は発生しませんか?」

理想的には、いいえ。autotools (「CMI」) セットアップの要点の 1 つは、パッケージャーが、このような問題が存在する場合に対処するためのメカニズムを実装できるようにすることです。同じライブラリの複数のバージョンをインストールできます。WRT ヘッダーは、それらが変更された場合でも、ライブラリ自体と同様に、(うまくいけば) 下位互換性を維持します。そうでない場合は、これを明示的に示す必要があります (「バージョン 2 はバージョン 1 と互換性がありません!」)。その場合、頭脳を持つ人なら誰でも最初からバージョン 2 の個別のヘッダーを持ち、API でそれを参照します。 .

于 2012-05-06T15:23:03.017 に答える