aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/common/options/Option.java
Commit message (Collapse)AuthorAge
* Remove wrapper options support.Gravatar ccalvarin2017-12-19
| | | | | RELNOTES: None. PiperOrigin-RevId: 179588174
* Expand implicitRequirements in the location of the option that required it.Gravatar ccalvarin2017-10-13
| | | | | | | | | | | Removes the special casing of implicit requirements. Accumulating them and parsing them at the end of the parse() function was never enough to actually guarantee that the value not be replaced. I've gone through all options with implicit requirements to make sure that the expectation is checked after options parsing, so this change should be relatively safe. Implicit requirements is still a broken concept - they don't actually expand based on the value given, so a user that is explicitly NOT setting a flag might unwittingly be setting all the requirements for that unset flag. Removing it fully requires redesigning or removing the flags that set it, though, so for now we are standardizing the behavior so that it behaves like any other expansion options, just one with a value. Also consolidate the deprecated wrapper option behavior into the expansion work. It will soon be removed entirely, but for now it can get grouped in with the expansion logic, so that its differences are more explicit. RELNOTES: None. PiperOrigin-RevId: 171957502
* Deprecate wrapperOptions.Gravatar ccalvarin2017-09-21
| | | | | | | In order to discourage new uses (there shouldn't be any, but just in case), make it illegal to set wrapperOption=true for non deprecated options. RELNOTES: None. PiperOrigin-RevId: 169477990
* Update comments about the option processor.Gravatar ccalvarin2017-09-01
| | | | | | | There were a few places where the current state of the world was not clear. RELNOTES: None. PiperOrigin-RevId: 167273651
* Add OptionDefinition layer between the @Option annotation and its fields and ↵Gravatar ccalvarin2017-08-22
| | | | | | | | | | | the options parser. Removes any direct reads of the annotation outside of OptionDefinition. This allows for fewer manual checks for the annotation's existence, unifies error wording, and paves the way for potentially generifying the OptionsParser to accept different @Option-equivalent annotations. Also allows for cleanup of duplicate code by giving @Option-specific operations a clear home, such as sorts and default logic. In followup changes, we can eliminate some unnecessarily complex caching by instead memoizing values in the OptionDefinition. This will have the positive side effect of making sure reads come from the cached values. RELNOTES: None. PiperOrigin-RevId: 166019075
* Make the @Option annotation depend on the java version of the tagging enums.Gravatar ccalvarin2017-07-18
| | | | | | | The option filters proto dependency can be removed from the OptionsParser. This is in response to option parser users that want to avoid the bazel-internal proto file in their dependencies. RELNOTES: None. PiperOrigin-RevId: 162249778
* Fold OptionUsageRestrictions into OptionDocumentationCategory and ↵Gravatar ccalvarin2017-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
* Enforce the new category and effect tags.Gravatar ccalvarin2017-07-03
| | | | | | | | | | All options need to explicitly list their category and effect. If they are uncategorized, this makes the lack of information obvious. Remove defaults from the annotation to enforce this. Also enforce the sanity check that no option should have UNKNOWN or NO_OP effects listed with other effect tags. Includes some last default sets for options I missed in the previous mass-setting change, and some that were added since. PiperOrigin-RevId: 160641861
* Add option tagging and categorizing enums.Gravatar ccalvarin2017-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
* Deprecate use of option category to describe documentation level / usage ↵Gravatar ccalvarin2017-04-19
| | | | | | | | restrictions. Prevent the old category strings "undocumented," "hidden," or "internal" from being used as categories, to prevent developers from relying on deprecated behavior. PiperOrigin-RevId: 153525499
* Remove the overloading of option category to cover documentation level.Gravatar ccalvarin2017-04-18
| | | | | | | | This prevents having to parse the category, and allows the category to potentially be used in the future for information about all options, included undocumented, hidden, or internal options. Also rename DocumentationLevel to OptionUsageRestrictions, since INTERNAL was not really documentation related. PiperOrigin-RevId: 153367769
* Add expansion functions to options parserGravatar Jon Brandvein2017-03-22
| | | | | | | | | | | | This provides a way to programmatically define expansions of options based on what other options are defined for the parser. In particular, it will be used for the --incompatible_* changes mechanism, to turn on all incompatible change flags. Expansion functions are specified in the @Option annotation, similar to converters. They are computed when an OptionsParser is constructed, and inspect a preliminary version of its OptionsData to determine the expansion result. This is then cached in the final OptionsData used by the parser. Expansion information for usage strings is available, but only when the usage strings are obtained via the parser. -- PiperOrigin-RevId: 150817553 MOS_MIGRATED_REVID=150817553
* Create "internal" category of command-line options.Gravatar Michael Staib2017-03-20
| | | | | | | | | | | | | | | | | | | | This is intended to be used for "flags" which should never appear on the command line - things like configuration distinguishers, which are used internally and must be part of the build options, but should always be set to their default value at the top level. This is already a convention within Bazel, but doesn't actually work the way Bazel expects - flags with spaces can be set by simply escaping or quoting the spaces so that word splitting will not break on them. This means they can also be matched by config_settings, which pass a single string. Forbidding the parser from matching these flags solves both of these unintended cases. Existing cases like this have also been converted to internal. -- PiperOrigin-RevId: 150497246 MOS_MIGRATED_REVID=150497246
* Polish the command-line reference.Gravatar Ulf Adams2016-06-27
| | | | | | | | | | | - change options to print --foo=value - allow option to specify what "value" should be - update the documentation for the startup options - add some indentation to the descriptions - add some spacing between flag texts -- MOS_MIGRATED_REVID=125960618
* Fix OptionsParserImpl.clearValue (and invocation policy by extension) to workGravatar Alex Humesky2016-05-10
| | | | | | | correctly with flags that have expansion flags or implicit requirements. -- MOS_MIGRATED_REVID=121862297
* Delete the defaultMultipleValue field from options and refactor the logic ↵Gravatar Luis Fernando Pino Duque2016-04-20
| | | | | | | | | | | | | | | | for retrieving the default values of options. The field defaultMultipleValue was introduced in commit 51a491b89a9cd5f15c9a093a5693bc37e696e6e1 to allow defining a default value for options that set allowMultiple. However due to the limitations of the optionsParser end up being not useful since we cannot guarantee that an option that allows multiple has a converter that returns a list of values. Thus this CL deletes code that may confuse even more and clarifies the mechanism that the options currently use to obtain their default values. -- MOS_MIGRATED_REVID=120317261
* Add a new field to options called defaultMultipleValue which enables setting ↵Gravatar Luis Fernando Pino Duque2016-03-21
| | | | | | | | | | | | | | | default values for flags whose allowMultiple is true. The behavior is the following: - If allowMultiple is false then behave as previously. - Otherwise for retrieving the default we now look at defaultMultipleValue instead of defaultValue and in the process it will apply the converter to each element. If no defaultMultipleValue is specified then the default value will be an empty list. -- MOS_MIGRATED_REVID=117558645
* Adds an oldName attribute and a wrapperOption attribute to the @Option ↵Gravatar Alex Humesky2015-10-21
| | | | | | | annotation for the options parser. oldName indicates the old name for the option, and the option will be parsed under both name and oldName. wrapperOption indicates that the option is a wrapper for other options. For example, in "--foo=--bar=baz", --foo wraps --bar=baz. With wrapperOption set to true for --foo, the options parser will "unwrap" --bar=baz and parse them as top-level flags. -- MOS_MIGRATED_REVID=105924412
* Adds a mechanism for invocation policy. The policy is taken through the ↵Gravatar Alex Humesky2015-09-30
| | | | | | | --invocation_policy startup flag and allows an application invoking Bazel to set or override flag values (whether from the command line or a bazelrc). -- MOS_MIGRATED_REVID=104160290
* Rationalize copyright headersGravatar Damien Martin-Guillerez2015-09-25
| | | | | | | | | | | The headers were modified with `find . -type f -exec 'sed' '-Ei' 's|Copyright 201([45]) Google|Copyright 201\1 The Bazel Authors|' '{}' ';'` And manual edit for not Google owned copyright. Because of the nature of ijar, I did not modified the header of file owned by Alan Donovan. The list of authors were extracted from the git log. It is missing older Google contributors that can be added on-demand. -- MOS_MIGRATED_REVID=103938715
* Update from Google.Gravatar Han-Wen Nienhuys2015-02-25
-- MOE_MIGRATED_REVID=85702957