Basic theory of operation for using openembedded goes something like this:
I usually have project directories to work under each project in eg
/git/. Eg project foo has a working and source directory I use to
track it under /git/foo/. So I end up producing builds in
/git/foo/builds/ and working on source in /git/foo/src.
Openembedded is composed of many granular parts, but basically works like this: the minimal core is oe-core and bitbake; meta-* packages provide granularity and openembedded, yocto et al to tweak the minimal environment in useful ways.
So to get a naive working environment you need an environment like this:
/git/oe/oe-core - git checkout of oe-core
/bitbake - git checkout of bitbake
/meta-* - minimal set provided by oe-core, plus whatever you add
/oe-init-build-env
/build - created by sourcing oe-init-build-env. First argument
is name of this directory. Second argument is path to
bitbake, optionally assumed as sibling. This is actually
where your machine is customized.
Sourcing oe-init-build-env, when you are in this directory will
sniff and set up environment for you to begin building with bitbake
and build your build directory. Eg: . ./oe-init-build-env build
should produce a build directory with config for you to manage and
allow you to use bitbake properly.
You can make your setup more sophisticated by cloning local bare
repos stored locally elsewhere. You can also give oe-init-build-env a
second argument to the path of bitbake. Ie, you can check out bitbake
here: /git/oe/bitbake then set up your environment correctly using
. ./oe-init-build-env build ../bitbake. This allow the setup
environment script to setup your environment variables correctly.
oe-core is the minimal set needed. In addition other packages are
offered which provide overridden configuration, sometimes providing
bitbake inline, and providing a variety of meta-* packages which can
also be managed by bitbake. This offers quite a bit of flexibility,
allowing it to be customized by individuals and large organizations.
https://gist.github.com/gists/3194987
P.S. This is one area where I think Perforce does a better job in providing configuration management. This solution works, but Perforce ostensibly allows sharing configured views of a source tree in a way that is compelling in these types of use cases, where we rely on the user to configure their workspace correctly ad hoc. I usually don't recommend proprietary software, but shared configuration views are nice.
http://gumstix.org/software-development/open-embedded/161-openembedded-directory-layout.html