bazel - a fast, scalable, multi-language and extensible build system

	Commit message (Collapse)	Author	Age
*	Change cfg(HOST) to cfg(HostTransition.INSTANCE).	gregce	2017-12-21
\| \| \| \| \| \|	Preparatory step for removing ConfigurationTransition.HOST. PiperOrigin-RevId: 179838374
*	Replace all usages of Blaze's Preconditions class with guava.	tomlu	2017-11-09
\| \| \| \| \| \| \| \|	Blaze had its own class to avoid GC from varargs array creation for the precondition happy path. Guava now (mostly) implements these, making it unnecessary to maintain our own. This change was almost entirely automated by search-and-replace. A few BUILD files needed fixing up since I removed an export of preconditions from lib:util, which was all done by add_deps. There was one incorrect usage of Preconditions that was caught by error prone (which checks Guava's version of Preconditions) that I had to change manually. PiperOrigin-RevId: 175033526
*	Only load the whitelist for Android targets if they use feature flags.	mstaib	2017-09-21
\| \| \| \| \| \| \| \| \| \| \| \| \| \|	Currently, every Android-related top-level target will use the feature flag whitelist, regardless of whether it has any feature flags. This change makes it so that these targets only load the whitelist if they need it. In the process, it moves the value of the whitelist from the attribute definition method to outside of it. Because it's a builder, this is only a minor change to each callsite. RELNOTES: None. PiperOrigin-RevId: 169405621
*	Move RuleConfiguredTarget to lib.analysis.configuredtargets.	gregce	2017-09-19
\| \| \| \| \| \|	This is a trivial change with a large file footprint. PiperOrigin-RevId: 169169864
*	More BUILD file refactorings.	philwo	2017-09-06
\| \| \| \| \| \| \| \| \|	Split collect, concurrent, vfs, windows into package-level BUILD files. Move clock classes out of "util", into their own Java package. Move CompactHashSet into its own Java package to break a dependency cycle. Give nestedset and inmemoryfs their own package-level BUILD files. PiperOrigin-RevId: 167702127
*	Package whitelisting: New implementation for feature whitelisting	plf	2017-07-26
	This builds on top of mstaib's idea to use package groups to whitelist projects which can use certain features in the analysis phase. Instead of using configurations and a flag, this way of implementing whitelists requires using two helper methods, one that adds an implicit attribute to every rule that has functionality that must be whitelisted and a different method to check whether a given package is whitelisted to use that feature. RELNOTES:none PiperOrigin-RevId: 163200890