No description
72bab1707e
Previously, WalkDeps() would record that a module was visited after the first time it encountered the module irrespective of whether it recursed into or not. This change moves the recording so it happens only after it has been recursed into. Added TestWalkDepsDuplicates_IgnoreFirstPath to test the change. Without the change the test fails because it does not visit E. Test refactoring: * A depsMutator was added instead of relying on blueprintDepsMutator to allow different tags to be used for different dependency types. * Modified barModule and fooModule to support the new depsMutator and add support for another type of dependency that is ignored by the walking code. * Extracted walkDependencyGraph() function to reuse common code. |
||
---|---|---|
bootstrap | ||
bpfmt | ||
bpmodify | ||
deptools | ||
gotestmain | ||
gotestrunner | ||
loadplugins | ||
microfactory | ||
parser | ||
pathtools | ||
proptools | ||
tests | ||
.gitignore | ||
.travis.fix-fork.sh | ||
.travis.gofmt.sh | ||
.travis.install-ninja.sh | ||
.travis.yml | ||
blueprint.bash | ||
blueprint_impl.bash | ||
Blueprints | ||
bootstrap.bash | ||
context.go | ||
context_test.go | ||
CONTRIBUTING.md | ||
doc.go | ||
glob.go | ||
glob_test.go | ||
go.mod | ||
LICENSE | ||
live_tracker.go | ||
mangle.go | ||
module_ctx.go | ||
module_ctx_test.go | ||
name_interface.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 | ||
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.