私は間違った質問をしていると思われるので、ここに一連の関連する質問があります。関連する質問は、誰かが私の根本的な誤解が何であるかを識別するのに役立つかもしれません.
私は次のことを経験しました：
- https://www.yoctoproject.org/docs/2.6/ref-manual/ref-manual.html
- https://www.yoctoproject.org/docs/2.6/dev-manual/dev-manual.html
- https://www.yoctoproject.org/docs/2.6/sdk-manual/sdk-manual.html
bitbake を使用して、さまざまなターゲット アーキテクチャ向けの製品をビルドできる単一のビルド環境を探しています。
これこそが Yocto/OE の聖杯のようです。
最も機能的な x86_64 環境は次のものから得られたようです。
git clone git://git.yoctoproject.org/poky
SDK よりも優れていますが、この環境を別のプラットフォーム用にクロスビルドするにはどうすればよいですか?
git cloneこのような環境と同じくらい機能する SDK はありますか? 動作するビットベイクがあり、さまざまなターゲットのブータブル イメージをクロスビルドできるということですか?
質問:
SDK で SDK をビルドできないのはなぜですか? (例: http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/buildtools/ )
- SDK に bitbake が含まれていないのはなぜですか? (ext SDK はそうしますが、パスに追加するのは好きではありません)。
- 適切にソースされた env (およびパスに追加された bitbake) を持つ拡張可能な SDK が、SDK 内のものではなく、ディストリビューションでインストールされたビルド ツールを好むように見えるのはなぜですか? (devtool の代わりに bitmake を直接使用する場合)
SDK が明らかに特定のマシンまたはアーキテクチャ向けのビルドに関連付けられているのに、明らかに異なるアーキテクチャ向けのクロスビルドができないのはなぜですか? SDK を構築するプロセスでは、最終的なアーキテクチャを事前に指定することさえ望んでいます
私が慣れ親しんでいるのは、ソースがマウントされたある種の pseudo/proot/chroot の下で実行されるクロスツールチェーンを備えた build-sysroot です。
Yocto/bitbake が内部でこれを行っていること、すべてのレシピ キャッシングが優れていること、git clone チェックアウトが強力であること、devtool ワークフローが優れていることを認識していますが、この環境の生成を標準化しようとすると、またはクロスコンパイルします。
(ビルドを特殊化するためにいくつかのローカル conf ファイルを含むターゲット ディレクトリから環境ファイルをソースし、次に bitbake を使用してビルドを作成することを期待しています)
私は何を逃したのですか？- ここまで読んでくれてありがとう;-)