1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
|
<?xml version="1.0" encoding="UTF-8"?>
<chapter>
<title>Usage</title>
<section id="usage_introduction" xreflabel="introduction">
<title>Introduction</title>
<para>Using bitbake</para>
</section>
<section id="usage_workspace" xreflabel="workspace">
<title>Work space</title>
<para>The work directory (the working area) is where all of the source is
extracted, patched and built: ~/devel/oe/build/titan-glibc-25%> ls
tmp/work/strace-4.5.14-r1 image/ install/ strace-4.5.14/ temp/ The
subdirectories in the working area are: image When the install is being
run for the package it's files are installed into this directory. They are
moved out when being placed into individual packages and so only the
directores it created should remain. Any other that remain have not been
packaged. </para>
<para>install The install directory contains a subdirectory per package to
be created with the appropriate files located under each package (moved
from the image directory) and some files related to processing of the
packages. </para>
<para>strace-4.5.14 This is the directory created by the extracted source
code. (Refered to by the S variable in the recipes). </para>
<para>temp Scripts to perform the various stages (configure, compile, etc)
and the logs containing the output of those scripts. </para>
</section>
<section id="usage_tempdir" xreflabel="tempdir">
<title>Temp dir</title>
<para>The temp directory contains the scripts to perform various actions
and the log files generated by those actions:</para>
</section>
<section id="usage_installdir" xreflabel="installdir">
<title>Install dir</title>
<para>The install directory contains one subdirectory per package to be
generated, each containing the files to be included in that package, and
some package control files:</para>
<para></para>
</section>
<section id="usage_deploydir" xreflabel="deploydir">
<title>Deploy dir</title>
<para>The deploy directory is where the final packaged files (typically
.ipk files) and and flash images or nfs images etc end up. For our strace
example we end up with just two .ipk files, one for the application and
one for the documentation.</para>
</section>
<section id="usage_singlepkg" xreflabel="singlepkg">
<title>Working with a single package</title>
<para>When working on fixing and/or creating a single recipe you can ask
bitbake to deal with a single .bb file only. The -b <bb-file> option
asks bitbake to only process the named file. So to clean and rebuild a
single package you can do: %> bitbake -b <bb-file> -c clean %>
bitbake -D -b <bb-file> The various options that are useful here
are: -b <bb-file> Specify which recipe to process -c <action>
Specify which action to perform (see below) -D Enable debugging output.
This gives you a lot more output during the operation. -f Force on
operation. This is useful in getting bitbake to perform some operation it
normally wouldn't do. For example, if you try and compile twice ina row
then bitbake will not do anything on the second attempt since it has
already gone through the compile stage. By adding -f forces it the action
to take place. The most common actions (used with -c) are: fetch Will
download any files that need to be fetched. unpack Extracts the source
code into the working directory, but does not apply any patches. patch
Applies patches into the source in the working directory. configure Runs
the configuration task for the recipe. compile Actually compile
everything. stage Copy required files into the staging area. install
Install files that are going to be package. package Package files.
Normally this means creating the .ipkg files. clean Clean the package -
this deletes the entire working directory for the package, so on the next
build the source will be extracted, patches applied etc. Note that each
action will run any preceeding actions that have not yet been performed.
So starting with compile will also peform the fetch, unpack, patch and
configure actions. A typically development session would involve editing
files in the working directory and running: %> bitbake -f
packages/testapp/testapp_4.3.bb -c compile (Try and compile) look at logs,
edit some files in working area %> bitbake -f
packages/testapp/testapp_4.3.bb -c compile -f (Force re-compile) and then
once appropriate patches have been made and the recipe updated: %>
bitbake -f packages/testapp/testapp_4.3.bb -c clean (Remove working files)
%> bitbake -f packages/testapp/testapp_4.3.bb (Try everything from
scratch) A full list of available tasks for a specific package can be
obtained with the listtasks task: %> bitbake -f
packages/testapp/testapp_4.3.bb -c listtasks </para>
</section>
<section id="usage_bbinteractive" xreflabel="bbinteractive">
<title>Interactive bitbake</title>
<para>To interactively test things use: %> bitbake -i this will open
the bitbake shell. From here there are a lot of commands available (try
help). First thing you will want to do is parse all of the recipes.
BB>> parse You can now build a specific recipe: BB>> build
net-snmp If it fails you may want to clean the build before trying again:
BB>> clean net-snmp If you update the recipe by editing the .bb file
(to fix some issues) then you will want to clean the package, reparse the
modified recipe, and the build again: BB>> clean net-snmp BB>>
reparse net-snmp BB>> build net-snmp Note that you can use wildcards
in the bitbake shell as well: BB>> build t* The interacive mode was
most useful with bitbake versions prior to 1.4 where the entire set of
recipes had to be reparsed each time bitbake was run. Since bitbake 1.4
the parseing is cached between runs and so it is no where near as painful
to run individual bitbake commands and therefore the interactive mode is
no longer as important as it once was. [edit] </para>
</section>
<section id="usage_devshell" xreflabel="devshell">
<title>Devshell</title>
<para></para>
</section>
<section id="usage_workflow" xreflabel="workflow">
<title>Workflow</title>
<para>fetch Will download any files that need to be fetched. unpack
Extracts the source code into the working directory, but does not apply
any patches. patch Applies patches into the source in the working
directory. configure Runs the configuration task for the recipe. compile
Actually compile everything. stage Copy required files into the staging
area. install Install files that are going to be package. package Package
files. Normally this means creating the .ipkg files. </para>
</section>
</chapter>
|
