Add a dependency on the golang tool for each tool output file. This
will allow updating the go version without cleaning the output
directory.
Change-Id: I55048e96c8847635256bd9491e2cd12ddf29771b
Building cgofilter from main.ninja creates a circular dependency.
Move it to be built by the bootstrap stage instead, where go
files are built without cgofilter.
Change-Id: I853eb0b20a364adbfb93d44b039e1493214a6887
Regenerating build.ninja.in was non-deterministic, sort the maps
of name, value pairs before writing them.
Change-Id: I825734162b1adebc88ddb19d912751108322091e
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
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 makes the bootstrap script take two optional flag-based command
line arguments rather than using positional arguments. The -i argument
replaces the old positional arguments (one of which was simply not needed), and
the -r flag now causes the script to regenerate the bootstrap Ninja file for
use when working on Blueprint itself.
Additionally this change allows all the configuration variables used in the
script to be overridden by environment variables. This makes it possible to
create a very simple bootstrap script for a customized Blueprint-based build
system by invoking this script after setting up the proper environment
variables.
Change-Id: I60f890061ae237a68719e1e2d345d1a8e87c851c
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 adds a bunch of docs describing the bootstrap process. It also
renames a couple things in the source to better correspond with the terminology
used in the docs. On top of that it makes the standalone build to copy minibp
from the .bootstrap/bin directory to the bin directory to make it easier to
find.
Change-Id: Ibae3e607b59e2caf7d764ec3153155fde208ec1e
This change causes the module and singleton content in generated Ninja files to
be sorted by name.
Change-Id: I6e1fe6d4211111c7dfa25ebe0fc721701a6d0256
VariableConfigMethod creates a Ninja variable whose value comes directly from a
method on the config object.
Change-Id: I9baa3598678928ea3d5bc85b864b2df7d3e1b749
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
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
