| commit | 978c4aa92f3929e52f4502aff9246a236c6d56f9 | [log] [tgz] |
|---|---|---|
| author | Dan Willemsen <dwillemsen@google.com> | Mon Mar 20 14:11:38 2017 -0700 |
| committer | Dan Willemsen <dwillemsen@google.com> | Mon Mar 20 14:23:43 2017 -0700 |
| tree | b34cf4c404fa7fb15eba9c97fd0de2a49e27f6c1 | |
| parent | 28c7837b3dc409a2ce601db411eb6578cbec4933 [diff] |
Improve error messages when dependency variants are missing Instead of just saying: error: .../Android.bp:48:1: dependency "libc++" of "libtest" missing variant "arch:android_arm_armv7-a, link:shared, vndk:" Include a list of currently existing variants: error: .../Android.bp:48:1: dependency "libc++" of "libtest" missing variant: arch:android_arm_armv7-a, link:shared, vndk: available variants: arch:android_arm_armv7-a, link:shared arch:linux_x86, link:shared arch:linux_x86_64, link:shared arch:windows_x86, link:shared arch:windows_x86_64, link:shared This still isn't the best experience for users, but it at least provides enough information for someone more familiar with the build to understand the problem.
1 file changed
tree: b34cf4c404fa7fb15eba9c97fd0de2a49e27f6c1
- 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
- glob.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
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.