No description
244033b20f
Previously a LoadHook could not modify the name of a module because the module was registered before the LoadHooks were run. That made it very complicated (requiring mutators and auto generated names) to create a module type whose name was determined by say the directory in which it is defined. This change moves the LoadHook execution slightly earlier so it runs before registration of the module. That caused one slight side problem which was that the moduleInfo.Name() would fail when called in a LoadHook. That was because that gets the name from group.name but was group was nil because it is only set when the module is registered. Modifying the moduleInfo.Name() method to get the name from the module logicModule.Name() if group is nil fixed that. The reason for getting the name from the group.name rather than the logicModule.Name() is that the former tracks renames but the latter does not. However that is not an issue in this case as there has been no opportunity for the module to be renamed until after the LoadHook has returned. |
||
|---|---|---|
| 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.