i.MX Yocto Project: ltib versus bitbake

[#1]

NOTES:

• Empty cells do not mean there is no bitbake parameter for the corresponding ltib one. This is still work in progress.
• Both engines are completely different and doing a one-to-one comparison is not actually fair.
• The following tables compare the two core build tools, ltib for LTIB and bitbake for the Yocto Project (YP, hereafter). For YP, there is another important tool called HOB,  when appropriate, we add comments on the Comment's column.
• There are two main tables,
  • 'ltib modes versus bitbake'
  • 'ltib options versus bitbake'.

         We split in two based how ltib splits its parameter, so the order is the same as the one shown when typing './ltib --help'.

• LTIB comes in every released BSP, follow the User Guide to install it. The command 'ltib' is a script located on the folder with the same name, so all ltib commands should be run with './' as prefix
• YP can be seen of a series of layers (folders). To download these, including the Freescale layers, follow this link. The command 'bitbake' must be installed independently, you can either use the package manager of you OS (e.g. sudo apt-get install bitbake on Ubuntu) or download the source code and do the setup manually. Both ways should place the bitbake script into a executable path.

ltib modes versus bitbake

Mode description	ltib command	bitbake command	Comment
Just prep the package	ltib -m prep -p <package>	bitbake <package> -c patch	With bitbake when running the patch task, it executes two lower tasks: fetch and unpack. For example, if one wants a untouched (no yocto patches) kernel, one can try: 'bitbake linux-imx -c unpack' and code unpacked code is placed on tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/<version>/git/
rpmbuild -bc --short-circuit	ltib -m scbuild -p <package>	bitbake <package> -c compile	With bitbake running compile also runs a lower task: configure.
rpmbuild -bi --short-circuit	ltib -m scinstall -p <package>	bitbake <package> -c	With ltib the install task executes the %Install section of the package's spec. With bitbake the same task executes all related package's recipe install functions, e.g. do_install. Note: with ltib running a higher task (like scinstall) will not execute lower tasks (like scbuild and prep); this is not the case for bitbake: it runs lower tasks automatically.
does an scinstall followed by an install to the rootfs	ltib -m scdeploy -p <package>	bitbake <package> -c build	With bitbake, build is the default task, so one can even omit the -c build parameter, e.g. 'bitbake <package>'
generate and merge a patch (requires -p <pkg>)	ltib -m patchmerge -p <package>	NA	This is a pretty nice feature from LTIB, unfortunately with bitbake the command does not exit. For example, to patch the Kernel's recipe, take a look at this procedure. In case you follow all these steps to fix a bug, do not forget to send your patch to the community.
lean/uninstall target packages	ltib -m clean -p <package>	NA	With bitbake the 'clean' counterpart does not exit. If one needs to remove a specific package from a build, you may remove it from the image configuration file (e.g. file meta-fsl-demos/recipes-fsl/images/fsl-image-gui.bb, remove item on IMAGE_INSTALL variable); if package is inside a package group (e.g. ./meta-fsl-demos/recipes-fsl/packagegroup/packagegroup-fsl.bb) you may remove it there. After this change, bitbake again and the resulting image won't have the package. With HOB, this is much simpler due to its Graphical User Interface. Just type hob on your build directory, select the machine and the base image, then click on the 'Edit Image'. On that window you can easily deselect packages. Once deselection is done, build the image.
full cleanup, removes nearly everything	ltib -m distclean	NA	With bitbake the 'distclean' command does not exit. The way to remove all the built, remove the build/tmp folder. Be careful, next time you run bitbake, all tasks for all packages will be executed, in other words, you will start from scratch.
list packages (alphanumeric)	ltib -m listpkgs	non-GUI: bitbake -g fsl-image-gui && cat pn-depends.dot GUI: bitbake -g -u depexp fsl-image-gui	A bit more complex non-GUI: bitbake -g <image> && cat pn-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sort | uniq
list package names and licenses	ltib -m listpkgseula	NA	With HOB, you can see every package name name and its licence. Just type hob, then select the machine and image, and click on the 'Edit Image' button. On the 'All recipes' tab, you get a list of packages with their licenses.
list packages in twiki format	ltib -m listpkgstw	NA
list packages in a format for import into spreadsheet	ltib -m listpkgscsv	NA
make a binary release iso image	ltib -m release	NA
make a non-distributable test iso release	ltib -m trelease	NA
configure selected platform (no build)	ltib -m config	NA	There is no way to open a configuration menu with bitbake. Instead, you can use hob. With hob, things are much easier. Just type hob under the build folder and you can select the machine and the image. If the image you want does not fit to the ones already available, you can add packages manually and even store your new tuned image. NOTES: 1. On YP, an image is a similar concept as LTIB's package profile (usually called just profile). There are many predefined images which can be used as starting point, so type 'bitbake <image name>'. 2. In case the kernel needs to be configure, run 'bitbake linux-imx -c menuconfig'.
sub-platform selection (no build)	ltib -m selectype	NA	The selectype on LTIB opens two menus: 1. Platform and the Package Profile selection 2. Configuration menu (the same menu as the one shown with -m config). In case one needs to do execute just the first task, just run 'bitbake <image name>'. In case you need to execute both, run hob.
enter ltib shell mode (sets up spoofing etc)	ltib -m shell	bitbake <package name> -c devshell
import srpms into ltib (semi-automatic)	ltib -m addsrpms

ltib options versus bitbake

Option Description	ltib command	bitbake command	Comments
Root context number (0 is the primary and implicit)	ltib --rootn | ltib -R
operate on this package only	ltib --pkg | ltib -p	bitbake <package>	With bitbake there is no need to add a '-' parameter, just use the package name without the .bb extension
run the interactive configuration and build	ltib --configure  | ltib -c	NA	See the mode -m config for more info
run the sub-platform configuration and build	ltib --selectype	NA	See the mode -m selectype for more info
configuration file to build from (defaults to .config)	ltib --preconfig	bitbake <predefined image>	With bitbake use any of the predefined images (assuming that these have not been modified), e.g. bitbake core-image-minimal or bitbake fsl-image-gui (it happens to be the smallest and the largest image, in terms of number of packages)
profile file.  This is used to select an alternate  set of userspace packages, this is saved and used on later runs of ltib (e.g config/profiles/max.config)	ltib --profile
use this resource file	ltib --rcfile <f> | ltib - r <f>
batch mode, assume yes to all questions	ltib --batch | ltib -b
force rebuilds even if they are up to date	ltib --force | ltib -f	bitbake --force | bitbake -f	For example, to force recompiling the kernel: bitbake linux-imx -c compile -f
re-install rpms (but don't force rebuild)	ltib --reinstall | ltib -e	bitbake <package name> -c install -f
remove (erase) rpm	ltib --erase | ltib -E
turn off install/uninstall dependency checks	ltib --nodeps | ltib -n	bitbake -b <somepath/somefile.bb>	For example, to build just the kernel (no dependencies, just kernel): bitbake -b ../sources/meta-fsl-arm/recipes-kernel/linux/linux-imx_3.0.35.bb NOTE: ALL dependencies should be already be installed, otherwise the command will fail
don't force install rpms that have file conflicts	ltib --conflicts | ltib -k
keep the srpms after the build (deleted by default)	ltib --keepsrpms | ltib -s
more output	ltib --verbose | ltib -v	bitbake --verbose | bitbake -v	On YP, the log can be too verbose, so one way to handle the amount of log is to store it and then grep it: bitbake linux-imx | tee log; grep -i <your string to seach> < log
mostly a dry run (calls to system are just echos)	ltib --dry-run | ltib -d	bitbake --dry-run | bitbake -n
try to continue on package build errors (autobuilds)	ltib --continue | ltib -C	bitbake --continue | bitbake -k
print the application version and quit	ltib --version | ltib -V	bitbake --version
do not redirect any output	ltib --noredir | ltib -N
run the deploy scripts even if build is up to date	ltib --deploy | ltib -D	bitbake <image name> -f
disabled deployment (even with -p <pkg>)	ltib --no-deploy
just download the packages only	ltib --dlonly	bitbake -c fetchall <image name>	E.g. bitbake -c fetchall core-image-minimal
test that the BSP's packages are available	ltib --dltest
check against external staging repositories	ltib --external
leave the sources unpacked (only valid for pkg mode)	ltib --leavesrc | ltib -l	NA	This is the default mode in YP. All source code can be found on tmp/work. In case you want to remove source code after building (as in LTIB), add INHERIT += "rm_work" to your local.conf. NOTE: If your adding changes to a particular package, these will be lost. In case you want to keep source code of a specific package, include this on the RM_WORK_EXCLUDE variable (e.g. RM_WORK_EXCLUDE += "busybox eglibc").
Make the selected root number sticky	--sticky
Remove root stickiness	--no-sticky
(re)configure/build/install the host support package set	--hostcf
use with package listings	--enable
use if you really want to ignore any locks (careful!)	--ignorelock
used with -m release to copy additional content	--fullbsp
used with -m release to copy specical packages into ISO	--distmap
don't check sudo, work around for broken sudo (fc9)	--no-sudo
use git for some package's build where use-git-mode is either: internal    Use fsl internal git external   Use fsl external git	--use-git-mode
use external git for some package's build	--external-git
help on usage	--help | -h	--help | -h

[daiane_angolini]

Leo, that´s why I like to work with you! You are so nice =D

My points:

* You table is SUPER and I think it MUST be used (period)

* We can introduce the table with your sentence:

"both engines are completely different and doing a one-to-one comparison is not actually right, but see the table below"

What do you think?

[daiane_angolini]

or say "fair" instead of "right" :smileysilly:

[LeonardoSandova]

Sure Daiane, I agree with you, that phrase must be placed at the top of the doc.

[daiane_angolini]

ow. I just remembered one thing.

Adrian said me some time ago that the correct is use "Yoctoproject"

https://www.yoctoproject.org/sites/yoctoproject.org/files/11611_yocto_project_style_guide_070912_1.p...

I´ve been making this mistake all my life O.O

As your document is not published so far, try to keep the right standard :smileygrin:

[simon_cai]

yeah! i like leo too. his post fix some confusions of mine!