Śledzenie przypisania zmiennych w bitbake

Question

Używam bitbake/openembedded, ale mój przepis zawodzi, ponieważ niektóre zmienne ścieżki nie są poprawnie ustawione, tak myślę. W szczególności dodawanie plików do SRC_URI, ale błąd wskazuje, że próba skopiowania pliku odbywa się przy użyciu niewłaściwej ścieżki. Dlatego

1) Jak mogę sprawdzić „bieżący” path-zmienna użyta przy użyciu protokołu file: //

2) Biorąc pod uwagę, że w jakiś sposób potwierdzić których zmienna służy do wyszukiwania plików, mogę śledzić zadania do wspomnianej zmiennej na moim wykresie zależności? Chodzi mi o to, że bitbake musi napotkać appends/prepends do zmiennej w jakiejś kolejności w jakimś zbiorze plików receptur, które chciałbym sprawdzić, aby znaleźć mój błąd.

Dodatkowe pytanie: Myślę, że moje obecne " metoda debugowania "w celu wykrycia błędów w moich przepisach jest zbyt prymitywna (np. dodanie -D -D -D do linii poleceń, a następnie branie przez stosy wyników wyszukiwania w poszukiwaniu wskazówek). W jaki sposób "profesjonaliści" debugują swoje przepisy dotyczące bitbestów?

Aktualizacja: Znalazłem dużo lepszy sposób debugowania moich receptur:

Okazuje się, że po „fetch” zadaniem danego przepisu została pomyślnie zakończona, folder roboczy o przepis jest tworzone. Wewnątrz tego folderu znajduje się podfolder "temp" zawierający wykonany kod (np. Run.do_fetch. ######) i wyniki (np. Log._do_fetch. ######) dla każdego zadania w recepturze .

Sprawdzanie pliku "uruchom .. ###" powie Ci dokładną wartość dowolnej zmiennej oraz dokładne polecenia/funkcje Pythona wykonane dla zadania. Dane wyjściowe danego "przebiegu" są przechowywane w pliku "log .. ###" z tym samym identyfikatorem/numerem co plik "uruchom". W jakiś sposób ta bardzo podstawowa informacja nie została zarejestrowana podczas czytania instrukcji, ale teraz zawsze patrzę w folder "temp", gdy przepis zawodzi.

Answer 1

Zakładam, że odkryłeś bitbake-e, prawda? To zrzuca środowisko specyficzne dla "celu" pojedynczego bitu (tj. Przepisu). Uważam, że FILESPATH jest kluczową zmienną, którą bitBake wykorzystuje do znalezienia plików określonych w składniku file: // SRC_URI. Używanie bitbake -e (przepis) | grep^FILESPATH = wyświetli tę bardzo dużą zmienną ścieżki!

Nie wiem, jak śledzić przypisania do tej zmiennej, ale istnieje kilka sposobów na jej modyfikację. (Właściwie to przypominam sobie łatkę bitbake, która opisywałaby wyjście bitbake-e z tym, który plik zmodyfikował zmienną, ale nie może przywołać szczegółów.) Zapytaj na liście oe.) W każdym razie, jeśli usuniesz znak "=" z grep powyżej można zobaczyć inne sposoby można zmienić FILESPATH. Myślę, że jest to również uwzględnione w różnych dokumentach.

Wreszcie, powinieneś mieć więcej szczęścia z prośbą o otwartą listę mailingową, niż tutaj na stackoverflow.

Bitbake -e i pliki dziennika (znalezione w $ {WORKDIR}/temp) to najlepsze narzędzia do debugowania. (Sprawdź także ack-grep. Lepiej niż grep dla niektórych przypadków użycia bitbake.) Gdzie jest WORKDIR, pytasz?

bitbake -e (przepis) | grep^WORKDIR =

Po zapoznaniu się z WORKDIR, zobaczysz wzór i nie będzie musiał go znaleźć w ten sposób.

Happy baking!;)

Answer 2

Okazuje się, że istnieje patch dla tej operacji w nowszych wersjach BitBake, jej po prostu nie jest obsługiwana w jednym obecnie używam :-(

Answer 3

Sugerowałbym użyciu Toster, w interaktywny . W trybie strony konfiguracji, można śledzić zmienną historię przypisania

Atrapa jest tutaj:. https://www.yoctoproject.org/toaster/build-configuration.html

Aby go użyć, run „start źródło toster” po „źródła oe-startowych-build-env” i w interfejsie internetowym znajdziesz dane rejestrowane z twoich buildów

Nadzieja to pomaga, Alex