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

	Commit message (Collapse)	Author	Age
*	Categorize build options for BuildConfiguration.	gregce	2017-10-06
\| \| \| \|	PiperOrigin-RevId: 171017483
*	Document the options in smaller commands.	ccalvarin	2017-09-20
\| \| \| \| \|	RELNOTES: None. PiperOrigin-RevId: 169258065
*	Categorize query options.	janakr	2017-08-18
\| \| \| \|	PiperOrigin-RevId: 165581746
*	Add the option filter enums in java, with equivalence check.	ccalvarin	2017-07-17
\| \| \| \| \| \| \| \| \| \|	In order to break out the proto dependency of the OptionsParser, add a java-only enum that users of the options parser can depend on, instead of requiring the dependency on the protobuf. The protocol buffer definition is kept in order to be used for command line reporting in the BEP, so a test is added to make sure that the two are kept in sync. Also add some clearer guidance for how to go about selecting, and adding, option categories and tags. Migrating the current uses of the proto enum to this one will happen in a follow-up change. PiperOrigin-RevId: 161971077
*	First pass of @Option documentation for apple/objc/swift	cparsons	2017-07-13
\| \| \| \| \|	RELNOTES: None. PiperOrigin-RevId: 161720296
*	Fold OptionUsageRestrictions into OptionDocumentationCategory and ↵	ccalvarin	2017-07-11
\| \| \| \| \| \| \| \| \| \|	OptionMetadataTags. These are similar, no need to have both fields. Removing the "DOCUMENTED" default, the absence of UNDOCUMENTED will be used instead. Since requiring a documentation category for undocumented options doesn't make sense, list that as one of the OptionDocumentationCategories, but list HIDDEN and INTERNAL as part of OptionMetadata. These options should list UNDOCUMENTED as their category. PiperOrigin-RevId: 161515674
*	Add option tagging and categorizing enums.	ccalvarin	2017-06-27
	Begin work of transferring option categorization to a sustainable, documented setup. DocumentationCategories will replace the existing string category field, and will group flags in generated documentation. Each flag must belong to exactly 1 DocumentationCategory, whichever is most applicable or a new one. OptionEffectTags will document the effects of tags and will be used for filtering flags. These tags, unlike the categories, should be complete. All options that do affect Bazel's output should be tagged as affecting Bazel's output, for example. This is necessary for them to be useful when trying to isolate the cause of an issue or behavior by allowing irrelevant options to be filtered out. Each flag must have at least 1 intended behavior, so should have 1+ OptionEffectTag. If no effect tag applies, find a general tag that would apply and add it to all relevant options. OptionMetadataTags will hold information about the flag itself. Information about the lifecycle of a flag, for example, should belong in an OptionMetadataTag. It is useful for filtering, since it describes how trustworthy we might think the flag would be, but does not actually describe the “intent” or “meaning” of a flag. This can be an empty list, but options can also have multiple OptionMetadataTags All options will be switched from the old "category" field to this new system. A few general OptionsBases are provided as an example. PiperOrigin-RevId: 160180328