| commit | fce63d3c8fa746e31c486b515b1bcce26760b15d | [log] [tgz] |
|---|---|---|
| author | Dan Willemsen <dwillemsen@google.com> | Tue Nov 17 14:21:45 2015 -0800 |
| committer | Dan Willemsen <dwillemsen@google.com> | Tue Nov 17 17:08:05 2015 -0800 |
| tree | 85c4b9c8766bff11067cdfdffb7b431e938481c7 | |
| parent | ff7104f98ded5222d0dbd2cc7904cdef40a2f265 [diff] |
Add common implicit deps to Rules For implicit dependencies that will be common to all users of a Rule, add a new field 'CommandDeps' to the RuleParam. This is a list of strings to be prepended to the implicit dependencies in each BuildParam. This lets us have the dependencies declared next to where they are used, instead of duplicated in areas that may be far apart. I looked at passing this information down to ninja too, but it only saves us a few percent of ninja file, and requires a modification to the ninja file format. Change-Id: Ifd910dee1506d4e32a76ed06206f853c4caec622
3 files changed
tree: 85c4b9c8766bff11067cdfdffb7b431e938481c7
- bootstrap/
- bpfmt/
- bpmodify/
- choosestage/
- deptools/
- gotestmain/
- gotestrunner/
- loadplugins/
- parser/
- pathtools/
- proptools/
- tests/
- .gitignore
- .travis.fix-fork.sh
- .travis.install-ninja.sh
- .travis.yml
- Blueprints
- bootstrap.bash
- build.ninja.in
- context.go
- context_test.go
- context_test_Blueprints
- CONTRIBUTING.md
- doc.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
README.md
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.