特に、タグのセクションを参照してください。
この決定の背後にある理論的根拠は何でしたか? マージは、提案されている最新の binutils と GDB のビルド方法に影響しますか? （実際、私がチェックアウトしbinutils-2_25_1て実行したときmake all && make install、私も得gdbました。）
1837 次
1 に答える
18
変換を行いました。それらを結合リポジトリにした理由は、一部は歴史的であり、一部は実用的でした。
歴史的に、gdb と binutils はほぼ常に一緒に使用されてきました。それらは、Cygnus 内で維持されていたとき、単一のソース ツリー (「devo」と呼ばれる) にありました。その後、sourceware.org が設立されたときに、リポジトリ (「src」と呼ばれる) を共有しました。リポジトリは CVS モジュールを使用して、開発者がツリーの一部だけをチェックアウトできるようにしたため、これに気付いていないかもしれません。
実際には、gdb と binutils は多くのコードを共有しています。ビルド インフラストラクチャ (configureなど) を共有します。サポート ライブラリ (libibertyおよびinclude) ディレクトリを共有します。それらは BFD ライブラリを共有します。また、opcodes ライブラリを共有します。私にとっては、それらをまとめておく方が理にかなっています。これは、常にマージを行ったり来たりするのを避けるためであり (これは GCC の一部のコンポーネントで既に行われており、これは本当に面倒です)、1 つのプロジェクトへの変更が悪影響を与える問題を最小限に抑えようとするためでもあります。他に影響を与えます。たとえば、少なくとも理論的には、BFD で定期的に開発を行っている人は、gdbとbinutils の両方をビルドする必要があります。
configure共有リポジトリで使用される最上位のスクリプトにより、開発者は を使用して特定のディレクトリを無効にできます--disable-DIR。たとえば、gdb をビルドしたくない場合は、--disable-gdb.
于 2015-12-02T14:40:17.337 に答える