rattle: Forward build system, with caching and speculation

[ bsd3, development, library, program ] [ Propose Tags ]

A forward build system like Fabrciate but with speculation and remote caching.


[Skip to Readme]

Modules

[Index] [Quick Jump]

Downloads

Note: This package has metadata revisions in the cabal description newer than included in the tarball. To unpack the package including the revisions, use 'cabal get'.

Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees

Candidates

  • No Candidates
Versions [RSS] 0.1, 0.2
Change log CHANGES.txt
Dependencies base (>=4.9 && <5), bytestring, cryptohash-sha256, deepseq (>=1.1), directory, extra (>=1.6.14), filepath, hashable (>=1.1.2.3), shake (>=0.17.8 && <0.19), time, transformers (>=0.2), unordered-containers (>=0.2.7) [details]
License BSD-3-Clause
Copyright Neil Mitchell 2019
Author Neil Mitchell <ndmitchell@gmail.com>
Maintainer Neil Mitchell <ndmitchell@gmail.com>
Revised Revision 2 made by NeilMitchell at 2020-05-26T06:39:02Z
Category Development
Home page https://github.com/ndmitchell/rattle#readme
Bug tracker https://github.com/ndmitchell/rattle/issues
Source repo head: git clone https://github.com/ndmitchell/rattle.git
Uploaded by NeilMitchell at 2019-04-17T22:47:51Z
Distributions LTSHaskell:0.2, Stackage:0.2
Downloads 827 total (12 in the last 30 days)
Rating (no votes yet) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Docs available [build log]
Last success reported on 2019-04-17 [all 1 reports]

Readme for rattle-0.1

[back to package description]

Rattle Hackage version Stackage version Linux build status Windows build status

A very early prototype of a unique build system.

A forward based build system, where you can make calls to cmd. These are:

  1. Skipped if their inputs/outputs haven't changed
  2. Have their outputs copied in if only the outputs have changed
  3. Can be speculated in advance

The innovation over something like Fabricate is that I have a notion of hazards - if two rules write to the same file, or one writes after another reads, I consider that a build hazard and throw an error - the result is no longer consistent. For speculation, I just run commands that look useful and don't look like they'll cause a hazard. If speculation does cause a hazard, I give up and try again without speculation.

This build system fundamentally relies on tracing the files used by system commands, and currently uses the fsatrace program to do so, which must be installed. As a consequence of the design, if fsatrace fails, then rattle won't work properly. Example reasons that fsatrace might fail include:

  • If you use Go compiled binaries on Linux or Mac then it's unlikely to be traced, see Issue 24.
  • If you a Mac OS X 1.10 or higher then system binaries that themselves invoke system binaries they won't be traced, unless you disable System Integrity Protection (which you do at your own risk).
  • If you use statically linked binaries on Linux they probably won't be traced.

It is possible to write alternative tracing mechanisms that wouldn't have these limitations, for example:

  • Bigbro uses ptrace so works for Go binaries and statically linked binaries.
  • traced-fs is an unfinished file system tracer that implements a user file system that would also work for Go binaries and static linking.