# HG changeset patch # User Rob Landley # Date 1449696531 21600 # Node ID 1ba20659578121f16b663c8ebf59794a8bfe5f7a # Parent 2dd2e648c2ae12962f2f3ce81a3c765edc2b230c Update build-stages.html documentation. diff -r 2dd2e648c2ae -r 1ba206595781 www/about.html --- a/www/about.html Wed Dec 09 15:00:30 2015 -0600 +++ b/www/about.html Wed Dec 09 15:28:51 2015 -0600 @@ -41,6 +41,7 @@ from busybox, uClibc, and gcc/binutils to toybox, musl-libc, and lvm/lld.)

+

Using system images.

Each system image tarball contains a wrapper script ./run-emulator.sh diff -r 2dd2e648c2ae -r 1ba206595781 www/build-stages.html --- a/www/build-stages.html Wed Dec 09 15:00:30 2015 -0600 +++ b/www/build-stages.html Wed Dec 09 15:28:51 2015 -0600 @@ -18,18 +18,19 @@

Overview

-

The build runs the following stages, in order:

+

build.sh runs the following stages, in order:

The top level wrapper script build.sh runs the above stages in order, @@ -55,7 +56,7 @@

None of these scripts need to be run as root -- an explicit design goal of Aboriginal Linux is that root access on the host is never required.

-

Build stages

+

Files

The files in the top level directory of the Aboriginal Linux source are:

@@ -124,8 +125,8 @@ place are the same ones the scripts install into the target root filesystem.

This script populates the "build/host" directory, which is automatically -

used by later stages if it exists. It is not target specific, and only -

needs to be run once when building multiple architectures.

+used by later stages if it exists. It is not target specific, and only +needs to be run once when building multiple architectures.

@@ -159,9 +160,24 @@ 32 bit code. If you run "./cross-comiler.sh $TARGET" manually without setting CROSS_COMPILER_HOST, it defaults to i686.)

-

This compiler is statically linked against uClibc, for maximum +

This compiler is statically linked against musl-libc, for maximum portability. (You can set BUILD_STATIC=none to dynamically link instead, -but then have to install uClibc's shared libraries on the host.)

+but then have to install musl's shared libraries on the host.)

+ + + +
  • root-filesystem.sh $TARGET + +
    +

    Creates a root filesystem (with uCLibc, BusyBox, and an init script) +which contains just enough infrastructure to boot up to a shell prompt. +By default this is packaged as an initramfs, see SYSIMAGE_TYPE in config +to see other available filesystem types.

    + +

    This creates empty directories, copies the skeleton files from +sources/root-filesystem, builds toybox, and finally adds the contents +of the directory $MY_OVERLAY points to (if any). On appropriate hardware +(or with an appropriate emulator), you should be able to chroot into this.

  • @@ -181,55 +197,52 @@ -
  • root-filesystem.sh $TARGET - -
    -

    Creates a root filesystem (with uCLibc, BusyBox, and an init script) -which contains just enough infrastructure to boot up to a shell prompt. -By default this is packaged as an initramfs, see SYSIMAGE_TYPE in config -to see other available filesystem types.

    - -

    This creates empty directories, copies the skeleton files from -sources/root-filesystem, adds the contents of the directory $ROOT_OVERLAY -points to (if any), and builds toybox.

    -

    -

    The config variable ROOT_OVERLAY can add arbitrary files to this stage.

    -
    -
  • -
  • system-image.sh $TARGET
    -

    Packages up the root-filesystem (usually as a cpio.gz for initramfs), -builds a linux kernel (generally configured -for use with QEMU), and adds emulator launch scripts.

    +

    This does three things:

    +
      +
    • Packages up the root-filesystem (the default is cpio.gz for initramfs, +see SYSIMAGE_TYPE in config for alternatives) and the native-compiler +(as a squashfs).

    • +
    • Adds emulator launch scripts (usually for QEMU), see the +About page for details.

    • +
    • Builds a linux kernel, generally configured for use with QEMU).

    • -

      The kernel configuration combines the sources/baseconfig-linux settings +

      The mini.config file is the kernel configuration in +miniconfig +format (I.E. start from 'allnoconfig' and list the symbols you'd need to +switch on in menuconfig, allowing that to resolve dependencies as it goes). +It's created by combining the sources/baseconfig-linux settings (which are the same for each $TARGET) with the target-specific LINUX_CONFIG -entries from sources/targets/$TARGET. This configuration mechanism -(miniconfig) -essentially starts with "allnoconfig" and then switches on each mentioned -symbol, resolving dependencies as it goes, just as if you opened up menuconfig -and set that list of symbols by hand.

      - -

      You can also build your own kernel outside of this build system, using -the root-filesystem directory as your initramfs source.

      - -

      For more information on system images and launch scripts, see the -the binary docs

      +entries from sources/targets/$TARGET. This gives you a starting point +to build your own kernel and package up root-filoesystem in your own way +if you want to bypass the system-image.sh stage.

  • -

    The sources/more directory contains additional scripts the user can run, -but which are not called from build.sh. This directory contains the external -user interfaces the user can call directly which are not build stages. -See more/README in the Aboriginal source code for details.

    +

    The sources/ directory contains infrastructure, defining variables +and shell functions used by the rest of the build. Most prominently, the +the shell functions "setupfor" prepares a temporary copy of +the source (extract and patch the relevant source tarballs and cd into the +directory), and the shell function "cleanup" deletes that temporary copy +when finished. (The actual implementation has +some optimizations you can usually ignore.) +The function "build_section" does both and calls a build script from +sources/sections in between (see sources/sections/README for details).

    -

    The native-build.sh script in each system-image, and the -more/native-build-from-build.sh script, use build +

    The sources/targets/ directory contains all target-specific +information. Each target has a single file defining all target-specific +information, and adding a target just means adding a file to this directory.

    + +

    The more/ directory contains all the additional scripts the user may +want to run directly, but which aren't build stages.

    + +

    The more/native-build-from-build.sh script (which calls the +native-build.sh script in a system-image) uses build control images, externally supplied filesystem images (usually squashfs) -the system image's init script automatically mounts on /mnt. If the file -/mnt/init exists (I.E. an executable "init" script at the top of the +which the system image's init script automatically mount on /mnt. Then if the +file /mnt/init exists (I.E. an executable "init" script at the top of the build control image), the system image init script will run that file instead of dropping to a shell prompt. This allows arbitrary automated behavior out of the newly booted image, operating on supplied data.