[ostree/wip/multibuild] gnomeos: Add better README, keep working on bison/flex

[Colin Walters <walters src gnome org>]

commit 5eae810380e75779cbd41d9c821cde21c810eaea
Author: Colin Walters <walters verbum org>
Date:   Tue Jan 3 12:19:55 2012 -0500

    gnomeos: Add better README, keep working on bison/flex

 gnomeos/3.4/bison.txt               |    3 +-
 gnomeos/3.4/manifest.json           |    3 +-
 gnomeos/README                      |   56 +++++++++++++++++++
 gnomeos/README-testing-multiroot.md |  104 -----------------------------------
 4 files changed, 59 insertions(+), 107 deletions(-)
---
diff --git a/gnomeos/3.4/bison.txt b/gnomeos/3.4/bison.txt
index b1b7822..d7a031b 100644
--- a/gnomeos/3.4/bison.txt
+++ b/gnomeos/3.4/bison.txt
@@ -1,2 +1,3 @@
-SRC=git:git://git.savannah.gnu.org/bison.git
+UPSTREAM_SRC=git:git://git.savannah.gnu.org/bison.git
+SRC=git:file:///src/bison-with-po
 COMPONENT=devel
diff --git a/gnomeos/3.4/manifest.json b/gnomeos/3.4/manifest.json
index ccd4a78..d0fa360 100644
--- a/gnomeos/3.4/manifest.json
+++ b/gnomeos/3.4/manifest.json
@@ -5,9 +5,8 @@
 
   "components": [
    		"gtk-doc-stub",
-   		"gnulib",
-   		"flex",
    		"bison",
+   		"flex",
    		"gobject-introspection"
 		]
 }
diff --git a/gnomeos/README b/gnomeos/README
new file mode 100644
index 0000000..b024322
--- /dev/null
+++ b/gnomeos/README
@@ -0,0 +1,56 @@
+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.
+
+