Re: What Problem does BuildStream Resolve ?

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

On Thu, 2018-01-25 at 11:35 +0000, Paul Sherwood wrote:
> Hi folks,

Hi Paul,

I'm going to try to quickly run through the checklist you pasted the
other day rather than delving into this email thread, although I may
have a more elaborate responses after FOSDEM...

 o construction is deterministic
   - for a given set of inputs, we always get the same output

   This depends on reproducibility of source code as well, we
   have recently run tests which show that gnome builds are mostly
   reproducible, and are working on automating tests which buildstream
   consumers can use to test the reproducibility of their sources
   (similar to reprotest)

   - all dependencies are known and controlled

   Not sure the context of this, we have source aliasing and have
   the framework in place to automate mirroring; mirroring of
   sources to ensure you always have what you need is recommended,
   but not in scope for automating as a part of buildstream.

   - host tools and configuration do not affect the outpot

   Yes. This separation guaranteed by the sandbox.

 o cycle-time is minimised
   - we don't waste time constructing artifacts that already exist

   Yes, this is done with artifact sharing.

   - we monitor elapsed construction times, and make optimisations to
     minimise them

   Yes. We also have a benchmarking project which is underway which
   we can use to observe performance improvements or regressions over
   time; these will focus on specific areas of what buildstream
   actually does, as opposed to activities such as running a compiler
   with a client's build scripts; which is not something buildstream
   has control over.

 o setup time is minimised
   - setup process is obvious and fast (e.g. a single install command,
     or login to shared service)

     Yes, setting up buildstream should normally be more simple than
     setting up a complex build server like OBS, eventually this should
     be provided by your distro's package manager, too.

   - setup process is known to work, and installs the correct
     version(s) of everything

     The installation process is a part of our CI, every CI test
     that we do is done from a distribution tarball of buildstream
     which is first installed as a part of CI.

 o learning time is minimised
   - we use tools that are obvious and provide clear, fast feedback
   - documentation is clear, helpful, sufficient and concise

   We focus on the terse stuff first to make sure seekers get the
   accurate information; and moving towards beginner and tutorial
   like material now as well.

   We also ensure that all relevant documentation is built from the
   same repository, allowing us to easily gate features and
   enhancements on the necessary changes to the documentation.

   Useful, good documentation is going to be a continuous and
   ongoing process for the lifetime of buildstream development.

 o debugging time is minimised
   - tools are instrumented to support fast and effective debugging
   - tools behaviour is reliable (ideally deterministic)

   BuildStream itself provides some features to assist here, mostly
   only in terms of allowing non-strict build mode (quickly test
   without rebuilds of reverse dependencies), workspaces to quickly
   try out code changes, and incremental builds available in workspaces
   to make your edit/compile/test cycle faster.

   BuildStream does not offer deeper instrumentation tools, tools such
   as profilers and debuggers belong in the sandbox and it is up to
   the user and project author to test in an environment where they
   have provided the necessary instrumentation tools. 

 o construction works for all target architectures
   - friction and delta for different targets is minimised

   Currently we only support building on host-compatible architectures,
   bootstrapping is proven to work on intel 32/64bit variants as well
   as armv7 and aarch64.

   The user story for bootstrapping an entirely new machine
   architecture has already been explored and implemented however is
   not yet under CI (this proves quite tricky as you need to boot
   a minimal image under a foreign arch and assert that it builds
   all of buildstream's dependencies there, and that you can then
   run buildstream on the foreign target).

   After FOSDEM I will have more news on this, we will be exploring
   an interesting option to allow building on foreign architectures
   using either VMs or real hardware as "workers" in a distributed
   build farm setup.

Cheers,
    -Tristan