From e877fdd56731a068fe9a3700bdb7e3c79419dcaa Mon Sep 17 00:00:00 2001 From: Jamie Lenehan Date: Sat, 5 May 2007 01:55:14 +0000 Subject: usermanual: Add some details in the usage section on how to bring up a devshell. --- usermanual/chapters/usage.xml | 148 +++++++++++++++++++++++++++++++++++------- 1 file changed, 123 insertions(+), 25 deletions(-) (limited to 'usermanual') diff --git a/usermanual/chapters/usage.xml b/usermanual/chapters/usage.xml index e4f056a764..4c58fc700a 100644 --- a/usermanual/chapters/usage.xml +++ b/usermanual/chapters/usage.xml @@ -136,7 +136,7 @@ that this may not be exactly what see - there are a lot of options that can effect exactly how things are done, but it gives us a pretty good idea of whats going on. What we are looking at here is the tmp directory (as - specified by TMPDIR in your local.conf):%> find tmp -maxdepth 2 -type d + specified by TMPDIR in your local.conf):~%> find tmp -maxdepth 2 -type d tmp tmp/stamps tmp/cross @@ -314,7 +314,7 @@ tmp/work/sh4-linux/arpwatch-2.1a15-r2 distribution is using it. Using lzo 1.08 as an example we'll examine the contents of the - working directory for a typical recipe:%> find tmp/work/lzo-1.08-r14 -maxdepth 1 + working directory for a typical recipe:~%> find tmp/work/lzo-1.08-r14 -maxdepth 1 tmp/work/lzo-1.08-r14 tmp/work/lzo-1.08-r14/temp tmp/work/lzo-1.08-r14/lzo-1.08 @@ -413,7 +413,7 @@ tmp/work/lzo-1.08-r14/image So lets show some examples of the useful information you now have - access to. + access to. How about checking out what happened during the configuration of lzo? Well that requires checking the log file for configure that is @@ -748,7 +748,7 @@ NOTE: build 200705041709: completed x is implemented via a function called do_x in the class or recipe where it is defined. See places refer to the tasks via their name only and some with the - do prefix. + do prefix. You will almost certainly notice tasks beyond these ones - there are @@ -760,7 +760,7 @@ NOTE: build 200705041709: completed configure and compile tasks and another new task called qa_staging between populate_staging and build - tasks. The format validates the result of the + tasks. The former validates the result of the configure task and the late the results of the populate_staging task. @@ -813,12 +813,12 @@ NOTE: package perl-5.8.8: completed by passing it via the -b parameter. This option takes the recipe as a parameter and instructs bitbake to process the named recipe only. Note that this ignores any dependencies that are in - the recipe, so these must have already been built previously. + the recipe, so these must have already been built previously. Here's a typically example that cleans up the package (using the clean task) and the rebuilds it with debugging output - from bitbake enabled:%> bitbake -b <bb-file> -c clean -%> bitbake -b <bb-file> -D + from bitbake enabled:~%> bitbake -b <bb-file> -c clean +~%> bitbake -b <bb-file> -D The options to bitbake that are most useful here are: @@ -958,28 +958,28 @@ NOTE: package perl-5.8.8: completed actions. A typically development session might involve editing files in the - working directory and then recompiling until it all works:[... test ...] -%> bitbake -b packages/testapp/testapp_4.3.bb -c compile -D + working directory and then recompiling until it all works:[... test ...] +~%> bitbake -b packages/testapp/testapp_4.3.bb -c compile -D -[... save a copy of main.c and make some changes ...] -%> vi tmp/work/testapp-4.3-r0/main.c -%> bitbake -b packages/testapp/testapp_4.3.bb -c compile -D -f +[... save a copy of main.c and make some changes ...] +~%> vi tmp/work/testapp-4.3-r0/main.c +~%> bitbake -b packages/testapp/testapp_4.3.bb -c compile -D -f -[... create a patch and add it to the recipe ...] -%> vi packages/testapp/testapp_4.3.bb +[... create a patch and add it to the recipe ...] +~%> vi packages/testapp/testapp_4.3.bb -[... test from clean ...] -%> bitbake -b packages/testapp/testapp_4.3.bb -c clean -%> bitbake -b packages/testapp/testapp_4.3.bb +[... test from clean ...] +~%> bitbake -b packages/testapp/testapp_4.3.bb -c clean +~%> bitbake -b packages/testapp/testapp_4.3.bb -[... NOTE: How to create the patch is not covered at this point ...] +[... NOTE: How to create the patch is not covered at this point ...] Here's another example showing how you might go about fixing up the - packaging in your recipe:%> bitbake -b packages/testapp/testapp_4.3.bb -c install -f -%> bitbake -b packages/testapp/testapp_4.3.bb -c stage -f -%> find tmp/work/testapp_4.3/install + packaging in your recipe:~%> bitbake -b packages/testapp/testapp_4.3.bb -c install -f +~%> bitbake -b packages/testapp/testapp_4.3.bb -c stage -f +~%> find tmp/work/testapp_4.3/install ... -%> vi packages/testapp/testapp_4.3.bbAt this stage you play with +~%> vi packages/testapp/testapp_4.3.bbAt this stage you play with the PACKAGE_ and FILES_ variables and then repeat the above sequence. @@ -1001,7 +1001,7 @@ NOTE: package perl-5.8.8: completed
Interactive bitbake - To interactively test things use:%> bitbake -ithis + To interactively test things use:~%> bitbake -ithis will open the bitbake shell. From here there are a lot of commands available (try help). @@ -1023,7 +1023,105 @@ BB>> build net-snmpNote that you can use wildcards in the
Devshell - [To be done] + One of the areas in which OpenEmbedded helps you out is by setting + various environment variables, such as CC + and PATH etc, to values suitable for + cross-compiling. If you wish to manually run configure scripts and compile + file during development it would be nice to have all those values set for + you. This is what devshell does - it provides you with an interactive + shell with all the appropriate variables set for cross-compiling. + +
+ devshell via inherit + + This is the newer method of obtaining a devshell and is the + recommended way for most users now. The newer method requires that the + devshell class be added to you configuration by inheriting it. This is + usually done in your local.conf or your + distributions conf file:INHERIT += "src_distribute_local insane multimachine devshell" + + With the inclusion of this class you'll find that devshell is + added as a new task that you can use on recipes:~%> bitbake -b packages/lzo/lzo_1.08.bb -c listtasks +NOTE: package lzo-1.08: started +NOTE: package lzo-1.08-r14: task do_listtasks: started +do_devshell +do_fetchall +do_listtasks +do_rebuild +do_compile +do_build +do_mrproper +do_fetch +do_configure +do_clean +do_populate_staging +do_package +do_unpack +do_install +do_package_write +do_distribute_sources +do_showdata +do_qa_staging +do_qa_configure +do_patch +NOTE: package lzo-1.08-r14: task do_listtasks: completed +NOTE: package lzo-1.08: completed + + To bring up the devshell you call bitbake on a recipe and ask it + for the devshell task:~%> ./bb -b packages/lzo/lzo_1.08.bb -c devshell +NOTE: package lzo-1.08: started +NOTE: package lzo-1.08-r14: task do_devshell: started +[... devshell will appear here ...] +NOTE: package lzo-1.08-r14: task do_devshell: completed +NOTE: package lzo-1.08: completed + + How the devshell appears depends on the settings of the TERMCMD variable - you can see the default + settings and other possible values in conf/bitbake.conf. Feel free to try settings this + to something else in your local.conf. Usually you will see a new + terminal window open which is the devshell window. + + The devshell task is inserted after the patch task, so if you have + not already run bitbake on the recipe it will download the source and + apply any patches prior to opening the shell. + + + This method of obtaining a devshell works if you using bash as your shell, it does not work if you are + using zsh as your shell. Other shells + may or may not work. + +
+ +
+ devshell addon + + The devshell addon was the original method that was used to create + a devshell. + + It requires no changes to your configuration, instead you simply + build the devshell recipe:bitabike devshell + + and then manually startup the shell. Once in the shell you'll + usually want to change into the working directory for the recipe you are + working on:~%> ./tmp/deploy/addons/sh4-linux-erouter-titan-devshell +bash: alias: `./configure': invalid alias name +[OE::sh4-linux-erouter-titan]:~$ cd tmp/work/lzo-1.08-r14/lzo-1.08 +[OE::sh4-linux-erouter-titan]:~tmp/work/lzo-1.08-r14/lzo-1.08$ + The name of the devshell addon depends on the target + architecture, operating system and machine name. So you name will be + different - just check for the appropriate name ending in + -devshell. + +
+ +
+ Working in the devshell + + [To be done] +
-- cgit 1.2.3-korg