No description
7d0dddd84d
tl;dr: Read if you don't use the wrapper or use SKIP_NINJA
Previously, we were relying on the ninja behavior of restarting the
build when the build.ninja file was updated to switch between different
bootstrap stages. But that means that every step that could produce a
build.ninja must pass in order to switch to a different stage. That
wasn't a big problem when we had a two stage build -- there was very
little that could fail in the second stage before we chose to go back to
the first stage. But when we had a three stage build, it was possible to
get into a state (usually during development) where you were in the
second stage, but the build was failing because the first stage needed
to be run. This was fixed in
|
||
|---|---|---|
| bootstrap | ||
| bpfmt | ||
| bpmodify | ||
| deptools | ||
| gotestmain | ||
| gotestrunner | ||
| loadplugins | ||
| parser | ||
| pathtools | ||
| proptools | ||
| tests | ||
| .gitignore | ||
| .travis.fix-fork.sh | ||
| .travis.gofmt.sh | ||
| .travis.install-ninja.sh | ||
| .travis.yml | ||
| blueprint.bash | ||
| Blueprints | ||
| bootstrap.bash | ||
| build.ninja.in | ||
| context.go | ||
| context_test.go | ||
| CONTRIBUTING.md | ||
| doc.go | ||
| fs.go | ||
| LICENSE | ||
| live_tracker.go | ||
| mangle.go | ||
| module_ctx.go | ||
| ninja_defs.go | ||
| ninja_strings.go | ||
| ninja_strings_test.go | ||
| ninja_writer.go | ||
| ninja_writer_test.go | ||
| package_ctx.go | ||
| README.md | ||
| scope.go | ||
| singleton_ctx.go | ||
| splice_modules_test.go | ||
| unpack.go | ||
| unpack_test.go | ||
| visit_test.go | ||
Blueprint Build System
Blueprint is a meta-build system that reads in Blueprints files that describe modules that need to be built, and produces a Ninja manifest describing the commands that need to be run and their dependencies. Where most build systems use built-in rules or a domain-specific language to describe the logic for converting module descriptions to build rules, Blueprint delegates this to per-project build logic written in Go. For large, heterogenous projects this allows the inherent complexity of the build logic to be maintained in a high-level language, while still allowing simple changes to individual modules by modifying easy to understand Blueprints files.