Assignments to arbitrary variables are now supported in Blueprint
files. Variables cannot be reassigned, and they stay in scope for
the remainder of the current Blueprint file and any subdirs Blueprint
files. Variables can be used in place of a value in properites or
as an entry in a list.
Change-Id: I04447e4c541304ded802bb82d1ca4ce07d5d95d2
Allow properties structs to contain exported int and uint fields,
but only if they are tagged with blueprint:"mutated". These fields
will be copied by CopyProperties in order to propagate through
cloning during mutations, but can only be set by Mutators and not
by Blueprint files.
Change-Id: Ic462385799c77667e392f4928d02d424c8f8d900
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
CopyProperties expects to interfaces in a struct to be an
interface to a pointer to a struct, but expects to be called
on a struct. When a struct contains an interface, dereference
it twice with Elem() before calling CopyProperties on it.
Change-Id: I0d10aff87729273a025ab6d86239fd60662a20c0
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
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
