Parsing

Prima di passare al vedere come tutto quello che abbiamo visto finora si concretizza nella scrittura di un recipe, ci soffermiamo sulla fase iniziale di parsing effettuata da bitbake.

Come avevamo visto nella nostra introduzione a Yocto, la prima fase della build è appunto il parsing:

bitbake ha conoscenza della posizione della cartella build tramite la variabile di ambiente BUILDDIR. Dentro build si aspetta di trovare la cartella conf contenente local.conf e bblayers.conf. Entrambi sono file .conf e quindi possono contenere solo variabili bitbake, non funzioni o altro. Le variabili di questi due file verranno considerate di tipo globale per tutto il processo di build, quindi visibili in ogni momento e da ogni file bitbake (.bb*, .conf).

Elenchiamo le variabili più importanti.

local.conf inizializza le variabili:

• DISTRO
• MACHINE

bblayers.conf inizializza le variabili:

• BBLAYERS
• BBPATH
• BBFILES

Bitbake procede a esaminare ogni percorso assoluto contenuto in BBLAYERS, in cui troverà le directory di ogni layer. Per ogni layer ne legge il local.conf e aggiunge le variabili contenute alle variabili globali. Grazie a questo:

• a BBPATH aggiunge il percorso del layer
• a BBFILES aggiunge il nome di tutti i recipe del layer

Oltre ad aggiungere altre variabili di metadati riguardanti il layer.

Se il layer è di tipo Distro o BSP ed esiste un file .conf che abbia lo stesso nome di DISTRO o MACHINE, allora le variabili di tale file vengono aggiunte alle variabili globali.

A questo punto bitbake possiede le informazioni relative ai layer attivi riguardanti:

• recipe
• priorità

E aggregando i file .bb* riesce a definire i recipe completi relativi al progetto (quindi compresi di append vari).

Lo step successivo sarebbe di dire a bitbake quale recipe costruire per avviare il processo di build, però il parsing è ufficialmente terminato. Tutte le informazioni sono salvate in un database interno di bitbake.

CLI#

Per ispezionare i risultati del parsing ci tornano utili un paio di comandi:

bitbake -e

ci permette di ispezionare TUTTE le variabili globali del progetto. Per rendere la visione più comoda è meglio fare un redirect del comando su un file, ad esempio usando

bitbake -e > env_global.txt.

Se invece al comando forniamo il nome di un recipe come argomento, possiamo ispezionare tutte le variabili che risultano visibili al recipe, quindi quelle globali e quelle private del recipe:

bitbake -e busybox

In entrambi i comandi il flag -e indica environment e non contiene solamente variabili, ma anche tutte le funzioni definite e disponibili. Spesso compaiono delle funzioni anche nel primo caso, dove non viene specificato un recipe, perchè di default yocto attiva delle classi globali, che valgono quindi per qualunque recipe. Queste ad esempio servono per generare i file di log o fare dei test di sanity della build. L’output del comando è quindi molto molto molto lungo e per questo è consigliato salvarlo su file.