16

私はbitbake/openembeddedを使用していますが、パス変数の一部が正しく設定されていないため、レシピが失敗すると思います。具体的には、SRC_URIにファイルを追加していますが、エラーは、ファイルのコピーが間違ったパスを使用して行われたことを示しています。したがって

1）file：//プロトコルを使用するときに使用される「現在の」パス変数を確認するにはどうすればよいですか？

2）ファイルの検索にどの変数が使用されているかを何らかの方法で確認した場合、依存関係グラフでその変数への割り当てを追跡できますか？つまり、bitbakeは、いくつかのレシピファイルのセットで変数への追加/追加に遭遇する必要があります。これを調べてエラーを見つけたいと思います。

ボーナスの質問：レシピのエラーを検出するための現在の「デバッグ方法」は原始的すぎると思います（たとえば、コマンドラインに-D -D -Dを追加し、その後、出力の山を通り抜けてヒントを探します） ）。「プロ」はどのようにビットベイクレシピをデバッグしますか？

更新：レシピをデバッグするためのはるかに優れた方法を見つけました：

特定のレシピの「フェッチ」タスクが正常に完了すると、レシピの作業フォルダーが作成されます。このフォルダー内には、実行されたコード（run.do_fetch。######など）とレシピ内の各タスクの結果（log._do_fetch。######など）を含む「temp」サブフォルダーがあります。 。

「run..###」ファイルを調べると、変数の正確な値と、タスクに対して実行された正確なコマンド/Python関数がわかります。指定された「実行」の出力は、「実行」ファイルと同じID/番号で「log..###」ファイルに保存されます。どういうわけか、この非常に基本的な情報は、マニュアルを読んでいる間は登録されませんでしたが、レシピが失敗したときは常に「temp」フォルダーを調べます。

4

3 に答える 3

25

あなたが発見したと思いますよbitbake -eね？これは、単一のビットベイク「ターゲット」（つまりレシピ）に固有の環境をダンプします。ビットベイクがコンポーネントFILESPATHで指定されたファイルを見つけるために使用する重要な変数であると私は信じています。file:// SRC_URIを使用bitbake -e (recipe) | grep ^FILESPATH=すると、その非常に大きなパス変数が表示されます。

その変数への割り当てを追跡する方法はわかりませんが、変更する方法はいくつかあります。（実際には、どのファイルがどの変数を変更したかで出力に注釈を付けるビットベイクパ​​ッチを思い出しbitbake -eますが、詳細は思い出せません。oeリストで質問してください。）いずれにせよ、=上記のgrepから記号を削除すると、次のように表示されます。他の方法FILESPATHは変更できます。これはさまざまなドキュメントでもカバーされていると思います。

最後に、ここのstackoverflowではなく、 openembeddedメーリングリストで質問する方が幸運かもしれません。

bitbake -eとログファイル（にあり${WORKDIR}/tempます）は、最高のデバッグツールです。（また、チェックしてください。ビットベイク関連のユースケースよりも優れています。）どこack-grepに質問しますか？grepWORKDIR

bitbake -e (recipe) | grep ^WORKDIR=

に慣れるとWORKDIR、パターンが表示され、そのように見つける必要がなくなります。

ハッピーベーキング！;）

于 2012-11-21T23:22:34.187 に答える
0

インタラクティブモードでトースターを使用することをお勧めします。構成ページでは、変数の割り当て履歴を追跡できます。

モックアップはここにあります：https：//www.yoctoproject.org/toaster/build-configuration.html

これを使用するには、「sourceoe-init-build-env」の後に「sourcetoasterstart」を実行すると、Webインターフェイスでビルドからログに記録されたデータが表示されます。

これがお役に立てば幸いです、アレックス

于 2015-02-10T11:07:34.547 に答える
-1

結局のところ、BitBakeの新しいバージョンでこれを行うためのパッチがありますが、現在使用しているバージョンではサポートされていません:-(

于 2012-12-19T13:15:19.377 に答える