README

Sourcery Builder is an experimental system for building and testing
open source cross-compilation toolchains.  It is intended as a
potential replacement for the existing system used internally at
CodeSourcery / Mentor Graphics / Siemens, and builds on experience
from that system.

Sourcery Builder is licensed under the GNU Lesser General Public
License, version 2.1 or later, and requires Python 3.5 or later.

At present, Sourcery Builder is in the very early stages of
development.  Most of the intended functionality is missing and it is
not yet possible to use it for useful toolchain build and testing;
some things are hardcoded that are only appropriate for initial
prototype purposes.  Some key missing pieces are:

* Various pieces needed for isolation from the environment and robust,
  reproducible builds.

* Ensuring source packages contain release configs used even if the
  release configs are not part of a component or are part of a
  closed-source component.

* Various features for binary packages, including stripping packaged
  host binaries, separate debug info for packaged target binaries, and
  copying sources for target binaries into the binary packages for use
  in a debugger.

* Running any toolchain testsuites.

* Self-tests for some parts of the code ("sourcery-builder self-test"
  exists, but only tests some modules, while coding style is tested
  separately by the check-style script).

* Sanity checks in parts of the code.

* Formatted documentation (docstrings exist, but are not yet set up
  with reST formatting to produce overall documentation with Sphinx).

* Features needed for building for more hosts than just the build
  system, if any host uses native toolchain directory arrangements, or
  if one of the later hosts is the toolchain target and needs to build
  using the tools built for the build system.

* Features needed for building the same component more than once for
  the same host in different configurations (e.g. an offload
  compiler).

* Support for using parts of a toolchain that were previously built
  rather than always building everything from source.

* Generally most script and component features that are in the
  existing internal system but have not yet been implemented for this
  one, as not needed for an initial prototype demonstration.

* Any public feature roadmap or designs for missing features (some
  notes exist, but are not public).