TipsAndTricks/DebuggingAvoidingRebuilds

Imagine you want to debug which change in some early dependency is causing a particular build issue. You could bisect that early dependency and then wait for a complete rebuild each time and debug that way. There is a slightly more risky but faster approach you can take.

For this example, the early dependency is pseudo-native and the recipe producing the failure is e2fsprogs. We want to find out which change in pseudo-native causes a packaging issue in e2fsprogs.

First, we set the SRCREV we want to test in the pseudo recipe. We then build it with "bitbake -b virtual:native:pseudo_1.8 -c populate_sysroot". Here, we're telling it to build the 'native' BBCLASSEXTEND version of the recipe, we add _1.8 to the filename to differentiate the recipe we want compared to the _1.6.5 and _git versions and we specify which task we want. Since we changed SRCREV, we don't need to clean it, even the -b version uses checksums, just with truncated dependency chains limited to the extent of the recipe only.

With the pseudo=native version we want now built, you might think "bitbake e2fsprogs" would work however that has the full dependency tree which wouldn't match the truncated dependency tree checksum we just built so it would cause a rebuild of pseudo-native and all the dependencies of e2fsprogs. We can however run "bitbake -b e2fsprogs -c package_qa" which does do what we want.

Assuming we want to test another pseudo-native version, we can change SRCREV again and it will build the new version. This time however we need to run "bitbake -b e2fsprogs -c cleansstate" first since the checksum for e2fsprogs will not have changed and we don't want to use the existing build or any data from sstate.

Incidentally, to debug pseudo, you can change FAKEROOTENV in bitbake.conf to include PSEUDO_DEBUG=nfoPdeViDxy (or whichever flags you want, see pseudo -h output for more info).