57 lines
2.1 KiB
Plaintext
57 lines
2.1 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.
|
|
|
|
|