TipsAndTricks/CliBuildsInToasterBuilddir

How to Take Over a Toaster Build Dir from the Command Line

Suppose you have used toaster to add layers and do some builds in a couple of toaster projects. This results in a directory structure that could look something like:

build  
build-toaster-1  
build-toaster-2  
build-toaster-3  
downloads  
sstate-cache  
_toaster_clones

In this example, we'll assume that build-toaster-1 is a "master" project, build-toaster-2 is a "local" project, and build-toaster-3 is a "morty" project. Let's further assume you've used the Toaster web ui to configure the layers and their dependencies to have what you'd like in them, but would now like to continue to do your work by hand. If you start a new shell that does not have the env variable pollution of the shell from which you started Toaster, you can do a command line build in the build-toaster-XX directory just as you normally would.
A couple of caveats:

• You must start from a new shell, otherwise the environment variables the Toaster startup sets will cause issues.
• You need to set up the env in the new shell as if that toaster build dir were the main build dir. e.g.

 cd build-toaster-1;. <path>/poky/oe-init-build-env 

• You need to run bitbake like

 bitbake -R conf/toaster.conf -r conf/toaster-bblayers.conf<target> 

if you have added additional toaster layers to the project or

 bitbake -R conf/toaster.conf <target> 

if you have not.

• Since Toaster was not really defined for this workflow, the layers you have added are not written out to disk until a build is run from the Web ui. The smallest build you can run from the Web ui that will force all your configuration to be written to disk is quilt-native.
• If you edit the toaster*conf files by hand, and go back the the ui, it will break.
• If you made a project type other than local you may run into issues since the command line build will be using the same bitbake that you started toaster from (the definition of a local project) , but if you made a past release project, this command line approach would be trying to use those layers targeted to an older release from a newer bitbake; which may or may not work.
  • For example, building a morty project from a master at 2.3 M2 did not work. If I wanted to set up a Morty project from toaster, I would need to start with a Morty Toaster...
  • But, since the poky I started toaster from was within 100 commits of master, the master project did work...