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
