Modify the Generate phase to call GenerateBuildActions inside a
goroutine to allow parallization. All modules from a single
moduleGroup are called from a single goroutine, and the goroutines
that processed all dependencies must have finished, so the only
change to the semantics of GenerateBuildActions implementations
is around access to globals. Locks are added to the lazily
created package context variables and to the live tracker.
Reduces run time by ~33%.
Change-Id: I62a515acf86f1dcecb093ded83444b920ff603be
Allows modules to determine if they are the last of their variants
to build, and to visit each variant to collect shared information.
Change-Id: I396f0c9d43e0e9b1901822d6dd9c6ad6380ad582
A future patch will rewrite context and module_ctx to support multiple
variants of a single module. This requires adding a layer of indirection
between the module defined in a Blueprint file and the Module object
built by the build logic.
What used to be called a moduleInfo struct is now a moduleGroup struct,
and contains the generic information taken from the Blueprint file.
Inside the moduleGroup struct is a list of moduleInfo structs, which
contain a logicModule pointer to the Module object returned by the
ModuleFactory function from the build logic. moduleInfo also contains
the name of the variant, as well as the dependencies after they have
been resolved from Blueprint string dependencies to dependencies on
a specific Module.
Change-Id: Id4d516ffc13381c3ce07b80eaf32d9090ae43703
DynamicDependerModuleContext is really a base module context used
by multiple types of ModuleContext interfaces. Rename it to
BaseModuleContext, and create a new DynamicDependerModuleContext
that just wraps it.
Change-Id: Ibb402e1d680d50ed15d6548e99b32cc0b5b52b12
Call PreGenerateBuildActions on each module that implments it after
resolving dependencies but before calling GenerateBuildActions on
any module. This allows the build logic to propagate top-down
information, for example what variants of a library need to be
compiled for the binaries it is used in.
Change-Id: I2737504fa9d1a2b42ef747497de32c1c5129233d
This adds (to the ModuleContext) a facility to check if a property is
defined in a module in a Blueprints file.
Change-Id: I16a35fd236717d8797f15093c019f7cc1049fb3c
This change replaces the automatic caller package divination with a
PackageContext object that must be explicitly passed in by callers.
Change-Id: I139be29ecf75a7cf8488b3958dee5e44363acc22
This change adds the DynamicDependerModule interface. Any Module type that
implements that interface will be called before Blueprint does its depenedency
analysis to allow the module to add additional dependencies.
Change-Id: I4d9ef8663d187262dcd9a1ec410c180c3ca4f57d
This change makes the ModuleContext and SingletonContext methods respect the
caller's Go package when performing name lookups. It does this by re-parenting
the module or singleton's scope to the scope of the caller's package, thus
allowing a Module or Singleton to pass its context to a function defined in
another Go package and have the called function access variables and rules
defined in its own Go package.
Change-Id: Ifdec87ba3095a453b36fb00e38c0bb3a928a2b9b
- Make module 'new' functions return slices of properties structs rather than
just one.
- Fix a couple places where errors were being reported incorrectly.
- Add ModuleContext methods for dealing with other modules.
- Make property value unpacking skip unexported struct fields rather than
panicing.
Change-Id: I4775ef77ff0514fc2ce5abccbe2ce534c05272f4
This change adds two new kinds of checks to params validation. First, all
BuildParams must have one or more outputs. Second, any Pool or Rule referenced
must be visible within the Blueprint scope of the caller (e.g. if it's defined
in another Go package then an Import call must have been made). If either of
these conditions are violated it will result in a panic.
Change-Id: Ibacb42513882d914c94eade23ef17269db5e8730
This change removes the definition of the Config type in the blueprint package.
The type was simply an empty interface, and it seems more clear to just have
that be explicit in the APIs.
Change-Id: Ia23a978f28e8627f890f483f62536f67264401bf
This change fixes an issue where the re-bootstrapping process would overwrite a
newer bootstrap manifest with one that it generates using its older minibp. It
fixes the issue by only generating a new bootstrap manifest right after
rebuilding minibp (as part of the bootstrap process). It then uses an
additional rebootstrap iteration to replace the old bootstrap manifest with the
new one.
Change-Id: I16bad2f30f6ad7f10da07d77105e8745adec3650
Blueprint is a build system component that reads Blueprints files defining
modules to be built, and generates a Ninja build manifest that can be used to
perform all the build actions. It does not dictate or implement much build
policy itself, but rather provides a framework to ease the process of defining
build logic in Go.
The "blueprint" and "blueprint/parser" Go packages contain the functionality
for reading Blueprint files and invoking build logic functions defined in other
Go packages.
The "blueprint/bootstrap" Go package contains just enough build logic to build
a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic
defined in external Go packages. This can be used to create a minimal Ninja
file that's capable of bootstrapping a Blueprint-based build system from
source.
The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary
that includes the build logic defined in the "blueprint/bootstrap" package.
This binary can then create the Ninja file for the bootstrapping process.
Change-Id: I8d8390042372a72d225785cda738525001b009f1
