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
Walk the dependency tree once in order to create a list of modules
such that that any module is guaranteed to be later in the list than
any of its dependencies. Allows easily walking the tree in child-first
or parent-first order by walking the list in forward or reverse order.
Change-Id: I8f2013ebf700d1bc4c41b7898742a426f032ea2f
ninjaString's Eval() does not currently check if all of the variables
referenced by the Ninja string being evaluated are present in the
map provided by the caller. This commit adds such a check.
Change-Id: I15cf3c44cc1eedaf6f93a9533b8cdcbffd74992c
This change makes the Context.visitDepsDepthFirstIf() method descend into
modules for which the predicate is false rather than skipping their entire
sub-DAG.
Change-Id: I50564c69a714d5e199e1a51a8aa24162b0dc6f11
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 change makes the bootstrapping process remove any files that were
previously created by invoking a Ninja rule (i.e. they appear in the .ninja_log
file) but are no longer a build output target.
Change-Id: I3c78e563393b97f8ca196ac85c7caa2b3866ffa6
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 eliminates blueprint.ModuleType and replaces it with simple factory
functions. Rather than using the explicitly provided ModuleType names to
essentially identify the Go factory function in the generated Ninja files, we
now use the actual factory function name.
Change-Id: Ib7813e850322a82cc35cdc56bebff7d580a5c6ec
The default target selector uses the name of the host OS.
Modules can implement their own target selector by implementing
the context.TargetSelector interface and its unique selectTarget()
method.
Targets are defined this way in Blueprint files:
cc_library {
name: "libmylib",
deps: ["libmath", "libutils"],
zones: ["frontend"],
srcs: ["main.cpp"],
targets: {
darwin: {
moduleCflags: "-framework OpenGL -framework GLUT",
},
linux: {
deps: ["libx11headers", "libglu"],
},
},
}
In this example, a set of C flags are defined on OS X only and on
Linux, two new dependencies are added.
When a target is selected, its properties are merged with the properties
of the modules:
- a list is appended to the original list (see deps above)
- a string is concatenated to the original string
- a bool replaces the original bool
- a map adds or replaces the key/value pairs of the original map
Change-Id: Ic627d47f795d6a4ff56ca5f6f099cad157621af1
This change causes Blueprint to stop calling GenerateBuildActions on modules
when one such call results in errors being generated. If a module has failed
for some reason and another module depends on it, then processing the dependee
could end up trying to use the failed module, which may be in an invalid state.
Change-Id: I5cc165b7f4e169f90e9570ec7b2a5f9baac2895a
- 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 adds docs to all the blueprint package APIs except for the Module
and Singleton types and their corresponding context types.
Change-Id: I74aa48c7743086ad79b3122d5813f5c4823c6519
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 causes the module and singleton content in generated Ninja files to
be sorted by name.
Change-Id: I6e1fe6d4211111c7dfa25ebe0fc721701a6d0256
This change makes the module definition location that's included in the build
manifest comments use paths relative to the top-level source directory. This
should make the bootstrap build manifest not get regenerated when using a new
build directory.
Change-Id: I350562ad10aa52688c8841c96c6325502b0faa59
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
