Bitbake: CLI

Fino a qua è stata tosta e non sono convinto che questa parte sarà più semplice, anzi no dai, sì, alla fine sono solo comandi da terminale.

bitbake#

Quando facciamo il setup di un progetto Yocto (che vedremo a breve, giuro) avremo a disponizione il comando bitbake e anche altri comandi più specifici che ci torneranno molto comodi. Intanto parliamo di bitbake. Con bitbake -h possiamo visualizzare un aiuto che ci permette di capire cosa possiamo fare con il comando:

user@hostname:/workdir/build$ bitbake -h
usage: bitbake [-s] [-e] [-g] [-u UI] [--version] [-h] [-f] [-c CMD] [-C INVALIDATE_STAMP] [--runall RUNALL] [--runonly RUNONLY] [--no-setscene]
               [--skip-setscene] [--setscene-only] [-n] [-p] [-k] [-P] [-S SIGNATURE_HANDLER] [--revisions-changed] [-b BUILDFILE] [-D] [-l DEBUG_DOMAINS] [-v]
               [-q] [-w WRITEEVENTLOG] [-B BIND] [-T SERVER_TIMEOUT] [--remote-server REMOTE_SERVER] [-m] [--token XMLRPCTOKEN] [--observe-only]
               [--status-only] [--server-only] [-r PREFILE] [-R POSTFILE] [-I EXTRA_ASSUME_PROVIDED]
               [recipename/target ...]

It is assumed there is a conf/bblayers.conf available in cwd or in BBPATH which will provide the layer, BBFILES and other configuration information.

General options:
  recipename/target     Execute the specified task (default is 'build') for these target recipes (.bb files).
  -s, --show-versions   Show current and preferred versions of all recipes.
  -e, --environment     Show the global or per-recipe environment complete with information about where variables were set/changed.
  -g, --graphviz        Save dependency tree information for the specified targets in the dot syntax.
  -u UI, --ui UI        The user interface to use (knotty, ncurses, taskexp_ncurses or teamcity - default knotty).
  --version             Show programs version and exit.
  -h, --help            Show this help message and exit.

Task control options:

Si ci sono una marea di opzioni, vediamo le più comuni e utili.

bitbake -e ci permette di visualizzare le variabili disponibili dopo il parsing di bitbake. Sono tante tante.

bitbake <recipe> ci permette di costruire un determinato recipe.

bitbake <recipe> -c <task> ci permette di eseguire uno specifico task del recipe. Se questo ha delle dipendenze su altri task, anche questi verranno eseguiti.

bitbake --runall <task> ci permette di eseguire uno specifico task su tutti i recipe del progetto. Utile ad esempio per effettuare inizialmente il fetch su tutti i task, in modo da non doverci poi preoccupare che si generino dei fault di download durante la build completa.

bitbake <recipe> -f ci permette di forzare la costruzione di un recipe ed evitare che questo utilizzi la sstate-cache. Utile se stiamo modificando pesantemente un recipe e non vogliamo che questo utilizzi la cache invece di rieseguire tutto il processo. A volte capita.

bitbake <recipe> -f <task> stessa cosa, ma riferita ad uno specifico task del recipe.

bitbake -g ci permette di generare i file pn-buildlist e task-depends.dot che descrivono rispettivamente tutti i package della build e tutte le dipendenze tra i task della build.

task comuni#

Yocto prevede già dei task comuni a tutti i recipe, come ad esempio listtasks, il cui compito è quello di mostrare tutti i task associati al recipe:

do_build                              Default task for a recipe - depends on all other normal tasks required to 'build' a recipe
do_checkuri                           Validates the SRC_URI value
do_clean                              Removes all output files for a target
do_cleanall                           Removes all output files, shared state cache, and downloaded source files for a target
do_cleansstate                        Removes all output files and shared state cache for a target
do_collect_spdx_deps                  
do_compile                            Compiles the source in the compilation directory
do_configure                          Configures the source by enabling and disabling any build-time and configuration options for the software being built
do_create_extlinux_config             
do_create_runtime_spdx                
do_create_runtime_spdx_setscene        (setscene version)
do_create_spdx                        
do_create_spdx_setscene                (setscene version)
do_deploy                             Writes deployable output files to the deploy directory
do_deploy_setscene                    Writes deployable output files to the deploy directory (setscene version)
do_deploy_source_date_epoch           
do_deploy_source_date_epoch_setscene   (setscene version)
do_devshell                           Starts a shell with the environment set up for development/debugging
do_diffconfig                         Compares the old and new config files after running do_menuconfig for the kernel
do_fetch                              Fetches the source code
do_install                            Copies files from the compilation directory to a holding area
do_listtasks                          Lists all defined tasks for a target
do_menuconfig                         Runs 'make menuconfig' in the compilation directory
...

I suggerimenti a fianco sono forniti dal flag [doc] associato a ciascun task.

Degli altri task molto comodi sono:

• clean rimuove la workdir di un recipe
• cleansstate pulisce la sstate-cache di un recipe
• cleanall rimuove workdir, sstate-cache e downloads di un recipe

oe-pkgdata-util#

Un altro comando estremamente comodo è oe-pkgdata-util che permette di analizzare i package che sono stati costruiti dalla build e capire quali recipe hanno contribuito a cosa. Ad esempio per capire quale recipe ha prodotto il file /usr/bin/app.config nel filesystem del nostro target.

Questo e altri comandi sono disponibili nella cartella scripts, presente solitamente a fianco delle cartelle bitbake e meta.

come al solito, con oe-pkgdata-util -h possiamo visualizzare un aiuto che ci permette di capire cosa possiamo fare con il comando:

user@hostname:/workdir/build$ oe-pkgdata-util -h
usage: oe-pkgdata-util [-h] [-d] [-p PKGDATA_DIR] <subcommand> ...

OpenEmbedded pkgdata tool - queries the pkgdata files written out during do_package

options:
  -h, --help            show this help message and exit
  -d, --debug           Enable debug output
  -p PKGDATA_DIR, --pkgdata-dir PKGDATA_DIR
                        Path to pkgdata directory (determined automatically if not specified)

subcommands:
  lookup-pkg            Translate between recipe-space package names and runtime package names
  list-pkgs             List packages
  list-pkg-files        List files within a package
  lookup-recipe         Find recipe producing one or more packages
  package-info          Show version, recipe and size information for one or more packages
  find-path             Find package providing a target path
  read-value            Read any pkgdata value for one or more packages
  glob                  Expand package name glob expression
Use oe-pkgdata-util <subcommand> --help to get help on a specific command

Tra i sottocomandi più interessanti abbiamo:

oe-pkgdata-util find-path <path> che ci permette di capire quale package ha prodotto il path nel nostro target filesystem. Il path è quindi da intendersi quello finale che il target userà a runtime, quindi una cosa tipo /usr/bin/app.config.

oe-pkgdata-util lookup-recipe <package> che ci permette di capire quale recipe ha prodotto il package che ci interessa. Utile da usare in combinazione col comando precedente.

Il comando oe-pkgdata-util in sostanza lavora con quello che i recipe definiscono nella variabile FILES, che appunto indica dove inserire determinati file nel filesystem del target.

runqemu#

Questo è un altro comando interessante perchè permette di simulare il nostro target all’interno di una macchina virtuale.

more commands