The closures in parseNinjaString seem to confuse go's escape
analysis, causing it to allocate a new stateFunc object on the
heap for every character in the string. Convert the state
functions to normal functions, and pass a pointer to a state
object to provide access to the variables that were in the
closure.
The range iteration on the input string was iterating over
UTF-8 runes, when all of the rune comparisons for state
changes only look at ASCII bytes. Switch to iterating
over bytes, stringState will pass through multi-byte
characters in strings untouched.
Together this reduces the time spent in parseNinjaString by
>50%, and the overall execution time by >20%.
Change-Id: I4c926b52b883d51e2f12a1673d03fcc2cfe83445
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 removeAbandonedFiles perform some of the string substitutions
that are done by the bootstrap script before considering whether a built target
still exists. It fixes a bug where the bootstrap manifest would get deleted
and subsequently regenerated, resulting in more re-bootstrap iterations than
was necessary.
Change-Id: I946c883dcc31fb77496f64d2573b395ad2cf095d
An Optional flag on buildDef is not very useful on its own,
BuildParams is what is exposed to modules.
Change-Id: I49b341654162adbc4eab884e88c21e68bbce8c75
Build definitions can now specify Optional. If Optional is not
specified the build definition will be followed by a default definition
for all outputs.
Change-Id: Iada83b2ef32bfb599b3cc580263f12bc002e1cdb
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 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
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
