Skip to content

Home

Jump to bottom
Andrew Zonenberg edited this page Sep 6, 2016 · 9 revisions

Splash is a parallel build system for multi-language / multi-architecture embedded projects

This is a from-scratch redesign of Andrew Zonenberg's original Splash project at http://redmine.drawersteak.com/projects/splash-build-system/. Its architecture is heavily inspired by Google Blaze, however it differs significantly from Blaze due to the target use case.

The code in this repository isn't even remotely close to usable or functional yet, have fun!

High level description

Splash is a build system which allows a build group of one or more developers' workstations to share a build cluster of one or more servers.

In a small-scale system this cluster may consist entirely of the workstations themselves (or even a single computer), although in a larger deployment it is likely that a dedicated cluster of build servers will be used.

Design goals/features:

  • Hash-based identification of build artifacts. The hash uniquely identifies an object file, executable, FPGA bitstream, etc by all factors which could cause it to change (compiler version, source/header file contents, target architecture, compiler flags, etc).
  • Support weakly reproducible/deterministic builds. A second Splash instance attempting to build the same target as another should invoke identical compiler(s) with the same arguments on identical source/library files. Bitwise identical output (strong reproducibility) is neither required nor guaranteed; while this would be ideal many FPGA tools use randomized place-and-route engines and not all allow the end user to control the placement seed. Splash also does not normalize executable header timestamps, so differences at these byte locations are to be expected. Reproducible building requires that the exact compiler version be specified which may reduce portability; use of less specific targets such as "c++/generic" provides the ability to build on a wider range of systems at the expense of reproducibility.
  • Minimize duplication of effort. If any user in the build group has compiled a given artifact, a cached copy should be made available immediately to any other user requesting it.
  • Minimize iteration time for development. All available CPU resources across the build cluster should be used when a build is requested so that the build completes as quickly as possible. This is crucial for developers to get feedback on their work.
  • Cross-platform/cross-architecture support designed from the start. Every Splashfile specifies which architecture(s) are being targeted, and the toolchain takes care of the dirty work.
  • Compiler/linker flags are abstracted so that developers can specify semantic flags like "use debug info" without worrying about the mess of /options and -options and -o's that their target's compiler requires.
  • Implicit support for unit testing: the results of a given test are simply a build artifact that depends on the test case and code being tested
  • Support for hardware-in-loop unit tests (where different test nodes may have different numbers/types of development boards attached).
  • Integration with some kind of CI dashboard

Links to stuff

TODO: organize this somehow

Clone this wiki locally