PropertyErrorf gets called from build logic, and shouldn't panic if the
build logic reports an error on an unset property. Fall back to using
the module position if the property wasn't set.
Also put the property name into the error message.
When appending properties, it may be necessary to determine if two
property structs are the same "type". A simple Go type comparison is
not sufficient, as there may be interface{} values in the property
structs that contain different types. Add proptools.TypeEqual that
returns true if they have equal types and all embedded pointers to
structs and interfaces to pointers to structs have the same nilitude and
type.
The only append semantics for bool that result in a no-op when the zero
value is appended is to OR the two values together, but that is rarely
the desired semantics. Add support for *bool and *string as property
types, where appending a nil pointer is a no-op. For *bool, appending a
non-nil pointer replaces the destination with the value. For *string,
appending a non-nil pointer appends the value.
This also provides a more reliable replacement for
ModuleContext.ContainsProperty, as the build logic can tell that the
property was set, even if it was set by a mutator and not by the
blueprints file, by testing against nil.
[]string already provides these semantics for lists.
Setting a *bool or *string property from a blueprints file is the same
syntax as setting a bool or a string property.
Add tests for CloneProperties, CloneEmptyProperties and ZeroProperties
and fix detected bugs related to nil pointers to structs and interfaces
containing nil pointers to structs.
It is common for a mutator to append or prepend property structs
together. Add helper functions to append or prepend properties in property
structs. The append operation is defined as appending string and slices
of strings normally, OR-ing bool values, and recursing into embedded
structs, pointers to structs, and interfaces containing pointers to
structs. Appending or prepending the zero value of a property will
always be a no-op.
DynamicDependencies can be implemented more flexibly by a
BottomUpMutator. If there are no DynamicDependencies, then
EarlyMutators are identical to BottomUpMutators. Deperecate both, and
reimplement DynamicDependencies inside a BottomUpMutator that is
guaranteed to be registered first.
walkDeps performs a pre-order DFS (unlike visitDepsDepthFirst which is
a post-order DFS). The visit function takes in both a parent and child
node and returns a bool indicating if the child node should be
traversed.
This removes the need to use $OLDPWD when running tests, which means
that the builddir may be an absolute or relative directory. It also
filters out the "PASS" message on successful test runs to clean up our
output.
Change-Id: I4ab937c7a87b74fe997a47cc0311e2f357f9f7e9
It's difficult for wrapping scripts to handle -b properly. Just pass
BUILDDIR instead, which is easier to handle. This still accepts -b, so
that incremental builds work across this change.
* commit 'ae9aa9216e1b08df5c3a6cfec97b3dae9a94afbc':
Implement plugins for bootstrap go modules
Fix bootstrap and separate buildDir ninja cleanup
context: Changed singletons to execute in order.
bootstrap: Added phony rule for bootstrapManifest.
Add new line to fatal error messages in bootstrap
bpdoc: Cache property struct docs by full package path
Now that we have multi-stage bootstrapping, we can make the primary
builder build more dynamic. Add the concept of plugins that will be
linked and loaded into bootstrap_go_binary or bootstrap_go_package
modules. It's expected that the plugin's init() functions will do
whatever registration is necessary.
Example Blueprint definition:
bootstrap_go_binary {
name: "builder",
...
}
bootstrap_go_package {
name: "plugin1",
pluginFor: ["builder"],
}
A package may specify more than one plugin if it will be inserted into
more than one go module.
Change-Id: I109835f444196b66fc4018c3fa36ba0875823184
With the introduction of $buildDir in bootstrapDir, the ninja cleanup
step hasn't been able to cleanup during the bootstrap stages. The main
stage was unaffected, as long as you were using "." as your buildDir.
Change-Id: I277dd7864989f9052d96cab9ce377548a1391a80
The full package path is no longer stored in the name variable, pass the
pkg variable into getDocs and putDocs so that types with the same name
in different packages don't collide.
Change-Id: I7ecd98815487467dbaadc8a318fa43b123fc83c1
* commit '150e16eab079358d95097f078c975d1b5933918f': (162 commits)
Support go 1.5
Fix bootstrap package build stage default
Support a separate build directory
Switch bootstrap.BinDir to a StaticVariable
Use three stage builds
Enhance bootstrap stage selection
Add test suite for bootstrapping
Switch to custom-built ninja v1.6.0
Migrate to container-based travis infrastructure
Fix running travis on forked repos
Require ninja 1.6.0, remove workaround
Don't print module header if nothing is defined
Fix a sub-Blueprints deps bug.
Add deep Copy() for parser types
Refactor parsing to allow reuse
Add convenience methods to Comment objects
Add self-documenting support
Support filtering nested structures by tag
Add option to build and run tests during bootstrap
Create internal bootstrap Config struct
...
The go compiler and linker changed in v1.5 -- to 'go tool compile' and
'go tool link' instead of 6g and 6l. Move the selection logic to
bootstrap.bash, and have it use compile/link if 6g/6l are missing. This
way the build.ninja.in will continue working with either go 1.4 or 1.5.
Travis and the test suite will fail under 1.5, since the build.ninja.in
is still generated with 1.4, and the function names in the comments
differ between 1.4 and 1.5.
The Go race detector found a race condition in the parser, which
highlighted a few related bugs. A variable could be defined but
not referenced in a Blueprints file, then appended to in multiple
subdirs= Blueprints files. The race detector caught the multiple
writes to assignment.Referenced from the parsers for the subdirs
Blueprints files, but multiple appends would be much more serious.
To fix this, keep local and inherited variables separate in the
Scope object and export that info to the parser. Disallow
appending to non-local variables, which was already the intended
behavior. Only update the referenced boolean for local variables.
Together, this should prevent all writes to Assignment objects
from parsers other than the one that created them.
Also improves the error handling code and some error messages.
Change-Id: Idb4f7d2e61bbe28d90b93074764e64e60d1eba8f
To provide a consistent __FILE__ behavior with cpp, we want to be able
to run with SRCDIR="." and the outputs be saved elsewhere. Other tools
within android also expect to be run from $TOP.
Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
API Change -- will require changes to any code using bootstrap.BinDir
This way we can put references to other variables in BinDir, and still
be used properly by other packages.
Change-Id: I497424cb254b3a170401ac9420fa0adbf8d11d1e
