diff options
Diffstat (limited to 'README.structure')
-rw-r--r-- | README.structure | 214 |
1 files changed, 0 insertions, 214 deletions
diff --git a/README.structure b/README.structure deleted file mode 100644 index 761b37b41f..0000000000 --- a/README.structure +++ /dev/null | |||
@@ -1,214 +0,0 @@ | |||
1 | A walk through the poky directory tree | ||
2 | ====================================== | ||
3 | |||
4 | Poky consists of several components and understanding what these are and where | ||
5 | they each live is one of the keys to using it. | ||
6 | |||
7 | Top level core components | ||
8 | ========================= | ||
9 | |||
10 | |||
11 | bitbake/ | ||
12 | |||
13 | A copy of bitbake is included within poky for ease of use and resides here. | ||
14 | This should usually be the same as a standard bitbake release from the bitbake | ||
15 | project. Bitbake is a metadata interpreter and is responsible for reading the | ||
16 | poky metadata and running the tasks it defines. Failures are usually from the | ||
17 | metadata and not bitbake itself and most users don't need to worry about | ||
18 | bitbake. bitbake/bin is placed into the PATH environmental variable so bitbake | ||
19 | can be found. | ||
20 | |||
21 | build/ | ||
22 | |||
23 | This directory contains user configuration files and the output from Poky is | ||
24 | also placed here. | ||
25 | |||
26 | meta/ | ||
27 | |||
28 | The core metadata - this is the key part of poky. Within this directory there | ||
29 | are definitions of the machines, the poky distribution and the packages that | ||
30 | make up a given system. | ||
31 | |||
32 | meta-extras/ | ||
33 | |||
34 | Similar to meta containing some extra package files not included in standard | ||
35 | poky, disabled by default and hence not supported as part of poky. | ||
36 | |||
37 | scripts/ | ||
38 | |||
39 | Various integration scripts which implement extra functionality in the poky | ||
40 | environment for example the qemu scripts. This directory is appended to the | ||
41 | PATH environmental variable. | ||
42 | |||
43 | sources/ | ||
44 | |||
45 | Whilst not part of a checkout, poky will create this directory as part of any | ||
46 | build. Any downloads are placed in this directory (as specified by the | ||
47 | DL_DIR variable). This directory can be shared between poky builds to save | ||
48 | downloading files multiple times. SCM checkouts are also stored here as e.g. | ||
49 | sources/svn/, sources/cvs/ or sources/git/ and the sources directory may contain | ||
50 | archives of checkouts for various revisions or dates. | ||
51 | |||
52 | Its worth noting that bitbake creates .md5 stamp files for downloads. It uses | ||
53 | these to mark downloads as complete as well as for checksum and access | ||
54 | accounting purposes. If you add a file manually to the directory, you need to | ||
55 | touch the corresponding .md5 file too. | ||
56 | |||
57 | poky-init-build-env | ||
58 | |||
59 | This script is used to setup the poky build environment. Sourcing this file in | ||
60 | a shell makes changes to PATH and sets other core bitbake variables based on the | ||
61 | current working directory. You need to use this before running poky commands. | ||
62 | Internally it uses scripts within the scripts/ directory to do the bulk of the | ||
63 | work. | ||
64 | |||
65 | |||
66 | The Build Directory | ||
67 | =================== | ||
68 | |||
69 | conf/local.conf | ||
70 | |||
71 | This file contains all the local user configuration of poky. If it isn't | ||
72 | present, its created from local.conf.sample. That file contains documentation | ||
73 | on the various standard options which can be configured there although any | ||
74 | standard conf file variable can be also be set here and usually overrides any | ||
75 | variable set elsewhere within poky. | ||
76 | |||
77 | Edit this file to set the MACHINE you want to build for, which package types you | ||
78 | which to use (PACKAGE_CLASSES) or where downloaded files should go (DL_DIR) for | ||
79 | exmaple. | ||
80 | |||
81 | tmp/ | ||
82 | |||
83 | This is created by bitbake if it doesn't exist and is where all the poky output | ||
84 | is placed. To clean poky and start a build from scratch (other than downloads), | ||
85 | you can wipe this directory. tmp has some important subcomponents detailed | ||
86 | below. | ||
87 | |||
88 | tmp/cache/ | ||
89 | |||
90 | When bitbake parses the metadata it creates a cache file of the result which can | ||
91 | be used when subsequently running the command. These are stored here, usually on | ||
92 | a per machine basis. | ||
93 | |||
94 | tmp/cross/ | ||
95 | |||
96 | The cross compiler when generated is placed into this directory and those | ||
97 | beneath it. | ||
98 | |||
99 | tmp/deploy/ | ||
100 | |||
101 | Any 'end result' output from poky is placed under here. | ||
102 | |||
103 | tmp/deploy/deb/ | ||
104 | |||
105 | Any .deb packages emitted by poky are placed here, sorted into feeds for | ||
106 | different architecture types. | ||
107 | |||
108 | tmp/deploy/images/ | ||
109 | |||
110 | Complete filesystem images are placed here. If you want to flash the resulting | ||
111 | image from a build onto a device, look here for them. | ||
112 | |||
113 | tmp/deploy/ipk/ | ||
114 | |||
115 | Any resulting .ipk packages emitted by poky are placed here. | ||
116 | |||
117 | tmp/rootfs/ | ||
118 | |||
119 | This is a temporary scratch area used when creating filesystem images. It is run | ||
120 | under fakeroot and is not useful once that fakeroot session has ended as | ||
121 | information is lost. It is left around since it is still useful in debugging | ||
122 | image creation problems. | ||
123 | |||
124 | tmp/staging/ | ||
125 | |||
126 | Any package needing to share output with other packages does so within staging. | ||
127 | This means it contains any shared header files and any shared libraries amongst | ||
128 | other data. It is subdivided by architecture so multiple builds can run within | ||
129 | the one build directory. | ||
130 | |||
131 | tmp/stamps/ | ||
132 | |||
133 | This is used by bitbake for accounting purposes to keep track of which tasks | ||
134 | have been run and when. It is also subdivided by architecture. The files are | ||
135 | empty and the important information is the filenames and timestamps. | ||
136 | |||
137 | tmp/work/ | ||
138 | |||
139 | Each package build by bitbake is worked on its own work directory. Here, the | ||
140 | source is unpacked, patched, configured, compiled etc. It is subdivided by | ||
141 | architecture. | ||
142 | |||
143 | It is worth considering the structure of a typical work directory. An example is | ||
144 | the linux-rp kernel, version 2.6.20 r7 on the machine spitz built within poky | ||
145 | which would result in a work directory of | ||
146 | "tmp/work/spitz-poky-linux-gnueabi/linux-rp-2.6.20-r7", referred to as WORKDIR. | ||
147 | |||
148 | Within this, the source is unpacked to linux-2.6.20 and then patched by quilt | ||
149 | hence the existence of the standard quilt directories linux-2.6.20/patches and | ||
150 | linux-2.6.20/.pc. Within the linux-2.6.20 directory, standard quilt commands | ||
151 | can be used. | ||
152 | |||
153 | There are other directories generated within WORKDIR. The most important/useful | ||
154 | is WORKDIR/temp which has log files for each task (log.do_*.pid) and the scripts | ||
155 | bitbake runs for each task (run.do_*.pid). WORKDIR/image is where "make install" | ||
156 | places its output which is then split into subpackages within WORKDIR/install. | ||
157 | |||
158 | |||
159 | The Metadata | ||
160 | ============ | ||
161 | |||
162 | As mentioned previously, this is the core of poky. It has several important | ||
163 | subdivisions: | ||
164 | |||
165 | meta/classes/ | ||
166 | |||
167 | Contains the *.bbclass files. Class files are used to abstract common code | ||
168 | allowing it to be reused by multiple packages. The base.bbclass file is | ||
169 | inherited by every package. Examples of other important classes are | ||
170 | autotools.bbclass which in theory allows any "autotooled" package to work with | ||
171 | poky with minimal effort or kernel.bbclass which contains common code and | ||
172 | functions for working with the linux kernel. Functions like image generation or | ||
173 | packaging also have their specific class files (image.bbclass, rootfs_*.bbclass | ||
174 | and package*.bbclass). | ||
175 | |||
176 | meta/conf/ | ||
177 | |||
178 | This is the core set of configuration files which start from bitbake.conf and | ||
179 | from which all other configuration files are included (see the includes at the | ||
180 | end of the file, even local.conf is loaded from there!). Whilst bitbake.conf | ||
181 | sets up the defaults, often these can be overridden by user (local.conf), | ||
182 | machine or distribution configuration files. | ||
183 | |||
184 | meta/conf/machine/ | ||
185 | |||
186 | Contains all the machine configuration files. If you set MACHINE="spitz", the | ||
187 | end result is poky looking for a spitz.conf file in this directory. The includes | ||
188 | directory contains various data common to multiple machines. If you want to add | ||
189 | support for a new machine to poky, this is the directory to look in. | ||
190 | |||
191 | meta/conf/distro/ | ||
192 | |||
193 | Any distribution specific configuration is controlled from here. OpenEmbedded | ||
194 | supports multiple distributions of which poky is one. Poky only contains the | ||
195 | poky distribution so poky.conf is the main file here. This includes the | ||
196 | versions and SRCDATES for applications which are configured here. An example of | ||
197 | an alternative configuration is poky-bleeding.conf although this mainly inherits | ||
198 | its configuration from poky itself. | ||
199 | |||
200 | packages/ | ||
201 | |||
202 | Each application (package) poky can build has an associated .bb file which are | ||
203 | all stored under this directory. Poky finds them through the BBFILES variable | ||
204 | which defaults to packages/*/*.bb. Adding a new piece of software to poky | ||
205 | consists of adding the appropriate .bb file. The .bb files from OpenEmbedded | ||
206 | upstream are usually compatible although they are not supported. | ||
207 | |||
208 | site/ | ||
209 | |||
210 | Certain autoconf test results cannot be determined when cross compiling since it | ||
211 | can't run tests on a live system. This directory therefore contains a list of | ||
212 | cached results for various architectures which is passed to autoconf. | ||
213 | |||
214 | Copyright (C) 2006-2007 OpenedHand Ltd. | ||