90 lines
2.8 KiB
Plaintext
90 lines
2.8 KiB
Plaintext
Overview
|
|
--------
|
|
|
|
The build process is divided into two levels:
|
|
|
|
1) Yocto
|
|
2) ostbuild
|
|
|
|
Yocto is used as a reliable, well-maintained bootstrapping tool. It
|
|
provides the basic filesystem layout as well as binaries for core
|
|
build utilities like gcc and bash. This gets us out of circular
|
|
dependency problems.
|
|
|
|
At the end, the Yocto build process generates two tarballs: one for a
|
|
base "runtime", and one "devel" with all of the development tools like
|
|
gcc. We then import that into an OSTree branch
|
|
e.g. "bases/gnomeos-3.4-yocto-i686-devel".
|
|
|
|
Now we also assume that you have ostree installed on the host build
|
|
system via e.g. jhbuild or RPM if doing a cross build. The core
|
|
ostbuild tool can then chroot into a checkout of the Yocto base, and
|
|
start generating artifacts.
|
|
|
|
Each generated artifact is committed to an OSTree branch like
|
|
"artifacts/gnomeos-3.4-i686-devel/libxslt/master/runtime". Then, a
|
|
"compose" process merges together the individual filesystem trees into
|
|
the final branches (e.g. gnomeos-3.4-i686-devel), and the process
|
|
repeats.
|
|
|
|
ostbuild details
|
|
-------------------
|
|
|
|
The simple goal of ostbuild is that it only takes as input a
|
|
"manifest" which is basically just a list of components to build. A
|
|
component is a pure metadata file which includes the git repository
|
|
URL and branch name, as well as ./configure flags (--enable-foo).
|
|
|
|
There is no support for building from "tarballs" - I want the ability
|
|
to review all of the code that goes in, and to efficiently store
|
|
source code updates.
|
|
|
|
For GNOME, tarballs are mostly pointless - it's easy enough to just
|
|
run autogen.sh. However there are two challenges:
|
|
|
|
1) Tarballs for modules which self-build-depend may include
|
|
pre-generated files. For example - flex's tarball includes a
|
|
generated .c file for the parser. For these, we can either move
|
|
the module build to the Yocto level (thus giving a convenient way
|
|
to pull in host files), or possibly add the ability to
|
|
hardlink/copy in host binaries to ostbuild.
|
|
|
|
2) Tarballs which include translations pulled from a different
|
|
location. For example - bison. For these, we basically have to
|
|
maintain our own git repositories.
|
|
|
|
|
|
|
|
building
|
|
--------
|
|
|
|
srcdir=/src
|
|
builddir=/src/build
|
|
|
|
cd $srcdir
|
|
git clone gnome:ostree
|
|
git clone git://github.com/cgwalters/poky.git
|
|
cd $builddir
|
|
. $srcdir/poky/oe-init-build-env gnomeos-build
|
|
# Now edit conf/bblayers.conf, and add
|
|
# /src/ostree/gnomeos/yocto
|
|
# to BBLAYERS.
|
|
|
|
bitbake ostree-native
|
|
bitbake gnomeos-contents-{runtime,devel}
|
|
|
|
# This bit is just for shorthand convenience, you can skip it
|
|
cd $builddir
|
|
ln -s tmp/deploy/images/repo repo
|
|
|
|
# Now create a file ~/.config/ostbuild.cfg
|
|
# example contents:
|
|
# [global]
|
|
# repo=/src/build/gnomeos-build/build/repo
|
|
# mirrordir=/src/build/ostbuild/src
|
|
# workdir=/src/build/ostbuild/work
|
|
# manifest=/src/ostree/gnomeos/3.4/manifest.json
|
|
|
|
ostbuild resolve
|
|
ostbuild build
|