aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/buildtool/BuildRequest.java
Commit message (Collapse)AuthorAge
* Move BuildView.Options to a new top-level classGravatar ulfjack2018-06-13
| | | | | | | This is in preparation for dismantling BuildView and merging the relevant parts into AnalysisPhaseRunner. PiperOrigin-RevId: 200391088
* Move storage of queryExpression for cquery out of BuildRequest and straight ↵Gravatar juliexxia2018-01-19
| | | | | | into processRequest method in BuildTool. This is an extension of CL/181816980 and prevents pollution of BuildRequest. PiperOrigin-RevId: 182576704
* Introduce the blaze cquery command as the new ui for configurable query.Gravatar juliexxia2018-01-12
| | | | | | | | | | | | | | | | | | before: blaze build --nobuild //foo --experimental_post_build_query="deps(//foo)" after: blaze cquery "deps(//foo)" pros of ui change: - more concise - assumes query expression targets == targets to be built (but allows for flexibility through --top_level_targets flag) - separate from build command - cquery command recognizes query options, build options, and its own unique set of options cons of ui change: - adds another command to blaze - recognizes options that don't actually work yet -> requires more option validation RELNOTES: None PiperOrigin-RevId: 181816980
* Consolidate instances of the --loading_phase_threads flag.Gravatar juliexxia2017-12-21
| | | | | RELNOTES: None. PiperOrigin-RevId: 179838936
* Consolidate instances of the --keep_going flag.Gravatar juliexxia2017-12-18
| | | | | RELNOTES: None. PiperOrigin-RevId: 179468685
* Rename OutputGroupProvider -> OutputGroupInfo.Gravatar dslomov2017-12-14
| | | | | RELNOTES: None PiperOrigin-RevId: 179046403
* RELNOTES: --keep_incrementality_data flag allows Bazel servers to be run in ↵Gravatar janakr2017-11-12
| | | | | | | | | | | | | | memory-saving non-incremental mode independent of --batch and --discard_analysis_cache. A command run with --nokeep_incrementality_data will discard data that would be needed for incremental builds. Subsequent commands can be sent to the same server, but they will not get the benefit of incrementality from this command. However, if --keep_incrementality_data is specified on a subsequent command, the commands after that will get the benefits of incrementality. There are two benefits to not being dependent on --batch. First, this allows Bazel servers to be run in extreme memory-saving mode without the startup penalties (JVM startup, JITting) that --batch execution imposes. Second, this allows Bazel developers to inspect the state of a Bazel server after an extreme memory-saving build. In order to avoid discarding data unnecessarily (for instance, on a "bazel info used-heap-size-after-gc" or "bazel dump --skyframe=summary") the actual resetting of the graph is done lazily, right before its use in SequencedSkyframeExecutor#sync. This is morally a partial rollback of https://github.com/bazelbuild/bazel/commit/98cd82cbdcac7c48164a611c5a9aa8fc2f1720ef. For now, our tests specify all of the flags. After this change sticks, I plan to get rid of the --batch flag from these tests, which should allow for some clean-ups. Eventually --batch and --discard_analysis_cache may not imply that we don't keep incremental state: we can require that it be specified explicitly. PiperOrigin-RevId: 175335075
* Replace all usages of Blaze's Preconditions class with guava.Gravatar tomlu2017-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
* Move SkylarkSemanticsOptions to the packages/ directory, alongside ↵Gravatar brandjon2017-10-07
| | | | | | | | | SkylarkSemanticsCodec Note that the syntax package and its test package still depend indirectly on the options parser via other Bazel-specific packages. RELNOTES: None PiperOrigin-RevId: 171342823
* Categorize build options for BuildConfiguration.Gravatar gregce2017-10-06
| | | | PiperOrigin-RevId: 171017483
* Use top-level targets' configurations for convenience symlinks.Gravatar mstaib2017-09-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a new flag, --use_top_level_targets_for_symlinks. Configuration-specific convenience symlinks (i.e., (prefix)bin, (prefix)genfiles, (prefix)testlogs) previously pointed at the one top-level target configuration. If there were multiple top-level target configurations, which could only happen when --experimental_multi_cpu was used, then no symlinks would be created, though they would not be deleted either. With the flag on, the output directories of the configurations actually used by the top-level targets (after rule class transitions etc.) are compared. If all targets with non-null configurations have the same configuration (or, more specifically, if all targets with non-null configurations have configurations with the same output directory), then a symlink is created pointing at it. Otherwise, the symlink is deleted, to avoid confusion with stale symlinks from old builds. Known changes in behavior WITHOUT the flag turned on: * In the --experimental_multi_cpu case, non-configuration-specific convenience symlinks (i.e., (prefix)(workspace) and (prefix)out) will always be created, even though they previously wouldn't have been created at all in this case. (should be harmless) * In the --experimental_multi_cpu case, configuration-specific convenience symlinks will be created if all configs have the same output directory. (should be safe, or specifically, should never happen because multi-cpu would necessarily change the output path, but shouldn't hurt anything even if it did) * In the --experimental_multi_cpu case, configuration-based convenience symlinks will be deleted if some configs have a different output directory. (slightly more noticeable since that will be every build using experimental_multi_cpu, but then, it is experimental) RELNOTES: None. PiperOrigin-RevId: 168720843
* Rename all logger instances to "logger" (instead "LOG" or "log").Gravatar lberki2017-09-05
| | | | | RELNOTES: None. PiperOrigin-RevId: 167505493
* Initial (partial) implementation of configured target query. Activated by ↵Gravatar janakr2017-08-21
| | | | | | | | | | | | | | | | | | | | | passing the --post_build_query flag to a build command, with a query expression as the argument. Bazel then executes this query on the configured target graph as constructed by the build command. Since the prepare graph -> query workflow is how SkyQueryEnvironment works, this is mostly just copying that. Main missing features/code cleanups: * Recursive target patterns (/...) are not supported. * There is no way to specify the configuration of the targets in your query. * Configuration output is totally opaque (just the hash, or null if no configuration). * More generally, no output options. * Some features (visibility, label attrs) not supported. * No edge filtering (host deps, implicit deps). * Aspects are totally ignored. * Graceful failure on errors, edge cases, incompatible flags (like the TAP flags that discard edges). * Code hygiene issues (calling test-only method to get to Skyframe graph, some code duplication across ConfiguredTargetQueryEnvironment and SkyQueryEnvironment). Most of the features I plan to leave to rules-side people, since I think they won't be too hard for a general Blaze developer to implement, and designing the right features and user interfaces for these things is better left to the rules side. PiperOrigin-RevId: 165747829
* 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
* Add the default category and tag to all options.Gravatar ccalvarin2017-06-28
| | | | | | | | Move the default from the annotation to every mention. This makes the incompleteness explicit. Will add the defaults to test targets in a separate change. Once all dependencies are cleaned up, the Option annotation will no longer allow options without the documentationCategory or effectTag, to prevent new options being added without categories while we migrate to the new option categorization. PiperOrigin-RevId: 160281252
* 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
* Bump the blaze max jobs and warning threshold to keep up with the times.Gravatar felly2017-06-14
| | | | PiperOrigin-RevId: 158847561
* Move the instrumentation filter computation to BuildToolGravatar ulfjack2017-06-06
| | | | | | | | | | | | | | | | | | Previously, it was in CoverageCommand, which led to all sorts of special casing and workarounds, because it required options editing, error handling during options editing, as well as early package path setup. It also caused us to duplicate target pattern evaluation for the coverage command. A semantic change is that the TestCommand can now also trigger the heuristic instrumentation filter computation, if collect_code_coverage is enabled; we might consider also enabling this for the BuildCommand, which can also have collect_code_coverage enabled (e.g., when a user wants to build a non-test binary with coverage instrumentation). Also remove a bunch of unnecessary AbruptExitException declarations. RELNOTES: bazel test now also computes a default instrumentation filter if --collect_code_coverage is enabled PiperOrigin-RevId: 158129953
* Make --aspects a repeatable flag.Gravatar dslomov2017-05-31
| | | | | RELNOTES: '--aspects' can occur more than once on the command line. PiperOrigin-RevId: 157568229
* Document output groups.Gravatar Dmitry Lomov2017-05-04
| | | | | | | Work towards #2880. Change-Id: I7b661e368c0bd60fc6bcc10c7c1d63b82ba9702e PiperOrigin-RevId: 154957882
* Store Skylark command-line flags in SkyframeGravatar brandjon2017-04-28
| | | | | | | | | This is the first of two CLs for making command line options able to affect the Skylark interpreter. It introduces SkylarkSemanticsOptions, and stores it as a precomputed (injected) value in Skyframe. The next CL will read these options from Skyframe when constructing the Skylark environment. This CL affects the dataflow from command/test initialization to Skyframe. Some code paths, like those used for testing, use the default SkylarkSemanticsOptions and therefore won't be able to use (for example) --incompatible_* flags. The call sites to update were found by searching for uses of defaultVisibility and working upward from there. RELNOTES: None PiperOrigin-RevId: 154432058
* Allow bypassing the automated detection of jobs when --jobs=auto.Gravatar jmmv2017-04-28
| | | | | | | | | | | | | | | | | | This is useful for the Blaze case where builds are cloud-backed. In that case, we need to use a very large number of jobs to handle the remote tasks, as each task is handled by a blocking thread controlled by jobs. We were previously doing this using an invocation policy, but the UI was extremely confusing: "blaze help build" would claim that the default for --jobs was "auto" when, internally, "auto" was being converted to the hardcoded number pretty much silently. However, explicitly specifying --jobs=auto on the command line yielded different behaviors. With this change, --jobs=auto works for both Bazel and Blaze and does sensible things in each case without the user having to know. RELNOTES: None. PiperOrigin-RevId: 154418572
* Split out option usage restriction from option category.Gravatar ccalvarin2017-04-18
| | | | | | | | | These are two different concepts. Do not remove category overload compatibility in this CL, to keep this change limited to converting the current uses of category. With some flyby formatting fixes on affected OptionsBases. RELNOTES: None. PiperOrigin-RevId: 153390002
* Automatically set --jobs based on the number of CPU threads.Gravatar Julio Merino2017-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change adds the new magic value "auto" to --jobs and makes this the default. When --jobs=auto, we determine the number of available CPU threads and set a reasonable value for --jobs based on this number. I'm explicitly not defining what "reasonable" means because we may want to change the heuristics later on. The goal here is to reduce the load on the system when running Bazel while not adversely affecting build times significantly. Previous versions of Bazel defaulted --jobs to 200, which could easily overload the local machine with a lot of processes. This value was derived from Blaze's default, which makes sense because most jobs are network-bound due to distributed execution; however, in the Bazel case, this never made sense and is actually harmful. This change was initiated by problems observed on Macs where Bazel would bring machines to their knees due to system resource overload. It's likely that the overload is caused by too much RAM usage rather than CPU, but both of these should go down with a more limited jobs value. Should help alleviate issue #1160. RELNOTES: The --jobs flag now defaults to "auto", which causes Bazel to use a reasonable degree of parallelism based on the local machine's capacity. -- PiperOrigin-RevId: 150466088 MOS_MIGRATED_REVID=150466088
* Global cleanup change.Gravatar Googler2017-03-03
| | | | | | -- PiperOrigin-RevId: 149089903 MOS_MIGRATED_REVID=149089903
* Convert --use_action_cache to a regular optionGravatar Googler2017-03-01
| | | | | | | | RELNOTES: Convert --use_action_cache to a regular option -- PiperOrigin-RevId: 148804881 MOS_MIGRATED_REVID=148804881
* Turn on output tree tracking.Gravatar Eric Fellheimer2016-08-11
| | | | | -- MOS_MIGRATED_REVID=129887102
* bazel: move the "--jobs too high" warning to documentation.Gravatar Googler2016-07-01
| | | | | | | | | | | | This warning is printed on every invocation, and the visual noise helps blind the user to other more imporant warnings. Presumably they have chosen to set --jobs high for a reason. Help them make a good choice with the documentation, then don't distract them further. RELNOTES: Remove warning for high value of --jobs. -- MOS_MIGRATED_REVID=126369509
* Take --output_tree_tracking out of experimental.Gravatar Eric Fellheimer2016-06-22
| | | | | -- MOS_MIGRATED_REVID=125467098
* Simplify the logic of determining output groups.Gravatar Alex Humesky2016-06-21
| | | | | -- MOS_MIGRATED_REVID=125368119
* Replace the occurrences of Constants.PRODUCT_NAME for a call toGravatar Luis Fernando Pino Duque2016-05-23
| | | | | | | | | BlazeRuntime#getProductName() or a reference to TestConstants.PRODUCT_NAME for tests. This CL prepares the codebase in order to delete the constant. -- MOS_MIGRATED_REVID=122993568
* Respect --noexperimental_check_output_files in FileSystemValueChecker. ↵Gravatar Nathan Harmata2016-03-25
| | | | | | | | | FileStateValues for output files can make their way into the Skyframe graph if a source file is symlink to an output file. Also fix a bug where ExternalFilesHelper#isExternalFileSeen would always return true after returning true once in the past. This meant if an external file ever made its way into the Skyframe graph, we would always do a full graph scan at the beginning of each build (iow, we would always waste some CPU time doing nothing interesting). -- MOS_MIGRATED_REVID=118190190
* Make help documentation for --experimental_output_tree_tracking more general.Gravatar Nathan Harmata2016-03-17
| | | | | -- MOS_MIGRATED_REVID=117383853
* Use Bazel Preconditions variant which avoids varargs array creationGravatar Mark Schaller2015-12-10
| | | | | | | Reduces garbage. -- MOS_MIGRATED_REVID=109914243
* Make --symlink_prefix= work as expected again (i.e. create links called ↵Gravatar Lukacs Berki2015-11-25
| | | | | | | "bin"/"genfiles" instead of the default ones) -- MOS_MIGRATED_REVID=108699595
* --output_groups overrides default output groups if set.Gravatar Googler2015-11-19
| | | | | | | | | | | If --output_groups is specified without a + or a - sign, it removes the default output groups used for artifact selection from targets. * Use output_groups=+<group_name> to add an output group, * Use output_groups=-<group_name> to remove an output group. -- MOS_MIGRATED_REVID=108247894
* Track the entire OutputService instead of just the BatchStatter.Gravatar Eric Fellheimer2015-11-16
| | | | | -- MOS_MIGRATED_REVID=107800790
* Move LoadingPhaseRunner.Options to top-level class LoadingOptions.Gravatar Ulf Adams2015-11-02
| | | | | -- MOS_MIGRATED_REVID=106836859
* Description redacted.Gravatar Googler2015-10-13
| | | | | -- MOS_MIGRATED_REVID=105214382
* 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
* Description redacted.Gravatar Dmitry Lomov2015-09-08
| | | | | -- MOS_MIGRATED_REVID=102498501
* Remove the awkward default value marker from --symlink_prefix.Gravatar Lukacs Berki2015-08-27
| | | | | | | The wording of the help text is somewhat awkward, but we cannot mention "Bazel" explicitly because the string "Bazel" comes from Constants.java . -- MOS_MIGRATED_REVID=101664076
* A prototype implementation of top-level aspects.Gravatar Dmitry Lomov2015-08-20
| | | | | -- MOS_MIGRATED_REVID=101033236
* Add --output_filter optionGravatar Kristina Chodorow2015-07-21
| | | | | | | Fixes #309. -- MOS_MIGRATED_REVID=98639996
* Description redacted.Gravatar Mark Schaller2015-05-21
| | | | | -- MOS_MIGRATED_REVID=93986544
* add OutputGroupProvider.DEFAULT_GROUPS for commonly built groupsGravatar Michajlo Matijkiw2015-03-18
| | | | | | | | | unit tests and main code have fallen out of sync a few times, so consolidating the defaults here to make mistakes harder later on. one could argue this also gives a little better mental locality. -- MOS_MIGRATED_REVID=88921641
* Remove dead blaze flag --show_builder_stats.Gravatar Laszlo Csomor2015-03-13
| | | | | -- MOS_MIGRATED_REVID=88428013
* Rename TopLevelArtifactProvider to OutputGroupProvider.Gravatar Lukacs Berki2015-03-05
| | | | | -- MOS_MIGRATED_REVID=87596401
* Remove --compile_only and --compilation_prerequisites_only; --output_groups ↵Gravatar Lukacs Berki2015-03-04
| | | | | | | can be used in their stead. -- MOS_MIGRATED_REVID=87334648
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-04 10:20:52 +0000