BuildSystemDetails

Directory Layout
The BuildSystem will create a fairly big directory tree for you. This is roughly what it contains after a build (along with a bunch of subdirectories)

oe `-- org.gumstix.oe
 * -- build
 * |-- conf
 * `-- tmp

There are, as you can see, two main directories: "build" and "org.gumstix.oe". The latter is the OE source directory, which includes all the bitbake recipes for building all the various packages that OE knows about. The "build" directory has 2 parts. All is described in more detail below.

BitBake Sources
org.gumstix.oe `-- site
 * -- _MTN
 * -- classes
 * -- conf
 * -- contrib
 * -- files
 * -- packages

This directory tree is where the recipes which bitbake follows for building packages are kept. If you want to change the way software is built in this system, this directory is the "source tree" where your changes should generally be made. It is somewhat complicated to do this, and a full explanation of how bitbake and OE work is not contemplated here. Please see | the OE site for more detailed info. This is a simple description of kind of where different bits go.

_MTN
This is simply a version-tracking directory for the monotone revision control system. It tracks which revision of what you have actually checked out currently in your directory. You generally don't want to edit this stuff by hand, but just let the "mtn" binary manage it for you.

classes
This is internal OE stuff, which basically includes recipe templates for bitbake. These "classes" are used in the various packages to be built, abstracting common features from them for re-use across packages.

conf
These recipes include basic configuration information for various setups, including definitions of machines (ie mapping from machine to CPU type, compiler options, etc). For gumstix, the relevant files in here are in the machine/gumstix*, machine/include/gumstix.inc, and distro/gumstix-distro.conf files, which define the machine and distro environments for the gumstix builds.

"machine" basically describes the target hardware. For example, it specifies that verdex uses a PXA270 which uses software FP, and can optionally have ethernet, wifi, etc.

"distro" basically configures which versions of what packages to use when there are choices -- for example it says things like "the OS should be linux" and "the C library should be uclibc". It also includes information on where pre-built binary packages can be found (FEED_URIS), and the filesystem for the rootfs.

contrib
Includes some meta-stuff like logos, support scripts, etc. You probably won't find yourself using this stuff much in the normal course of business.

files
Data files which some recipes use. I'm not sure what the criteria are for putting stuff here instead of in packages/*

packages
This is the main place where package recipes go for individual packages. There are some special kinds of packages which deserve some special mention here.

"tasks" are bundles of sub-packages designed for particular functionality. For example "task-base" defines all the bits needed for a minimal bootable command-line linux system running init. "task-native-sdk" includes all the packages you'd need in order to have a native development environment on your target machine, including binutils, gcc, etc, etc. Tasks basically provide a useful shorthand way of grouping related packages together.

"images" are definitions of complete setups that you might want to install on a "clean" machine. Generally, they'll be combinations of "tasks" but might also include the odd individual package as well. The "gumstix-small-image" which is what one generally builds for gumstix is one such image.

site
Not entirely sure -- looks like this directory provides some pre-defined settings for autoconf packages, probably for those packages which expect to be building on the deployment host and so wouldn't cross-compile properly normally.

Build directory
There are 2 main pieces here: "conf" and "tmp". "conf" contains only one file, which configures how your local bitbake will compile the bits of OE. Basically, it should be set up to define what subset of OE stuff you want to build. In our case, we want to build the gumstix stuff, and the file included in the default tarball should be pretty much what you want.

Then there's the "tmp" directory, which is generated when you use bitbake to build things.

build/tmp directory
This is where bitbake will spit out everything it builds:

tmp `-- stamps
 * -- cache
 * -- cross
 * -- staging
 * -- rootfs
 * -- deploy
 * `-- uclibc
 * |-- images
 * `-- ipk
 * -- work

These are the main subdirectories you care about:

build/tmp/cache
Contains cached versions of the bitbake recipes, parsed from org.gumstix.oe

build/tmp/cross
Contains cross-compiling tools used by bitbake to build native gumstix binaries. Your cross-compiler will ultimately end up in tmp/cross/arm-angstrom-linux-uclibcgnueabi/bin/gcc -- if you want to build your own binaries from your own sources, use this compiler.

build/tmp/staging
This directory contains installed versions of various bits of software which are to run on the build host in building the various packages. Things like autoconf, libtool, etc.

build/tmp/rootfs
This is a staging directory for the files which will end up getting combined into the rootfs image for the gumstix. This directory tree is a mirror image of what your final gumstix will look like when you end up booting it.

build/tmp/deploy
This directory is where the stuff which is to be installed on the gumstix ends up, in packaged form. There are 2 main kinds of packaging which OE does for you: generating a rootfs image (in JFFS2 format)/u-boot binary/uImage kernel image/etc, and all the ipkg binaries. The former are basically designed for writing raw, directly into flash on the target gumstix from within u-boot, to completely replace the software image on the gumstix. The latter are managed from within linux on the target gumstix, and allow you to customize installing/removing individual pieces of software on the machine.

build/tmp/work
This directory contains the working directories in which the packages are all compiled, before having their bits installed/packaged/deployed into the other directories mentioned above. This is where the source packages are untarred, pathced, configured, compiled.

build/tmp/stamps
This directory contains some OE magic for determining which packages have had what stages of building/installing/packaging performed on them.