| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
|
|
|
| |
This covers all builtins in classes that use SkylarkSignatureProcessor#configureSkylarkFunctions. Generally this means things you define with @SkylarkSignature.
It is now an error to call configureSkylarkFunctions multiple times for the same class. It should only be called in static initializers.
Runtime's static knowledge of builtins has been factored into Runtime.BuiltinRegistry.
RELNOTES: None
PiperOrigin-RevId: 178295926
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- remove BaseSpawn.Local; instead, all callers pass in the full set of
execution requirements they want to set
- disable caching and sandboxing for the symlink tree action - it does not
declare outputs, so it can't be cached or sandboxed (fixes #4041)
- centralize the existing execution requirements in the ExecutionRequirements
class
- centralize checking for execution requirements in the Spawn class
(it's possible that we may need a more decentralized, extensible design in
the future, but for now having them in a single place is simple and
effective)
- update the documentation
- forward the relevant tags to execution requirements in TargetUtils (progress
on #3960)
- this also contributes to #4153
PiperOrigin-RevId: 177288598
|
|
|
|
|
|
|
|
|
|
| |
Package specifications can now be prefixed with `-` to
indicate negation: the specification `-//foo/bar/...`
excludes all packages under `//foo/bar` that would otherwise
have been matched.
RELNOTES: Package specifications can now be prefixed with `-` to indicate negation
PiperOrigin-RevId: 176551382
|
|
|
|
|
|
|
|
| |
Add Apple Rules to index.
Closes #3992.
PiperOrigin-RevId: 175175081
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 174199997
|
|
|
|
|
|
|
|
| |
Minor change, but the Rules AppEngine now supports Python with Google App Engine, so it's more than just Java.
Closes #3837.
PiperOrigin-RevId: 171843168
|
|
|
|
|
|
| |
*** Reason for rollback ***
PiperOrigin-RevId: 171177811
|
|
|
|
| |
PiperOrigin-RevId: 171140260
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If setting flag --use_new_category_enum, group the options by the new categories in both the command line output and the "everything-as-html" output used for the generated docs at https://bazel.build/versions/master/docs/command-line-reference.html. In the html output, the effect and metadata tags are listed for each option, with links to their descriptions at the bottom of the page. The tags only appear in the terminal output in -l/--long/--help_verbosity=long, and only the names appear.
This is still experimental as the majority of options do not yet use the new categorization system. The new output can be seen in command-line-reference.html format by adding the new flag to the "help everything-as-html" line in //src/main/java/com/google/devtools/build/lib:gen_command-line-reference.
The html output is in the same order as before (by blaze rule, with inherited options not repeated), which means it still has duplicate options, that should ideally be fixed separately. I propose either dropping the high-level grouping and just grouping the options by documentation category, or potentially grouping them by optionsbase in some non-class-naming way, and listing the commands that they apply to, as more and more optionsbases are used by multiple commands without being inherited (for example, all BuildEventServiceOptions are listed 20 times). People probably use ctrl-f to navigate this page anyway. Once we know that we only list each option once, we can actually have links to the options, which will make it possible to have links in the expansion lists.
Issue #3758
RELNOTES: added experimental --use_new_category_enum to the help command to output options grouped by the new type of category.
PiperOrigin-RevId: 170116553
|
|
|
|
|
|
|
|
| |
targets.
This is more in line with what I believe is considered a best practice these days.
PiperOrigin-RevId: 168396725
|
|
|
|
| |
PiperOrigin-RevId: 168389301
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The RuleClassProvider includes a copy of the product name, parameterized
for both Blaze and Bazel. Apparently, this is exclusively there so that
the standalone docgen binary can "magically" guess the product name.
This is strange and adds additional complexity to the Bazel core codebase
for no strong reason. Instead, just add a new flag to docgen that takes
the product name and pass it in explicitly.
RELNOTES: None.
PiperOrigin-RevId: 167724033
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
PiperOrigin-RevId: 167477112
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
linux-sandbox has a useful option -R, that runs the spawn as fake
root. However, it's not exposed to Bazel rules. Here, we do that via
the "requires-fakeroot" tag.
One possible usecase: In combination with "block-network",
"requires-fakeroot" makes it possible to integration test services
that insist on listening on privileged ports.
Unsurprisingly, this is incompatible with --sandbox_fake_username.
Change-Id: I9e8ab4d4abf0e45626e005ff21f73e6c17de0788
PiperOrigin-RevId: 164961019
|
|
|
|
|
|
|
|
| |
(https://user-images.githubusercontent.com/744228/28495342-609be784-6efe-11e7-8403-0f3c5e892b13.png)
Closes #3436.
PiperOrigin-RevId: 163968685
|
|
|
|
|
|
|
| |
Fixes #2987.
Change-Id: I359a74b37a670e3953cc737a416c0e9573e547f0
PiperOrigin-RevId: 162738265
|
|
|
|
|
|
| |
links to "deptset" and "list".
PiperOrigin-RevId: 162607082
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 162373757
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
The page was incomplete and almost empty, and also redundant with
https://docs.bazel.build/versions/master/skylark/lib/globals.html#PACKAGE_NAME
RELNOTES: None.
PiperOrigin-RevId: 162234689
|
|
|
|
|
|
|
|
|
| |
Motivation: properly document config_setting.values.
The license type description is terse. But that's an obscure
feature we don't really want to focus attention on.
PiperOrigin-RevId: 161998339
|
|
|
|
|
|
|
| |
subinclude :)
RELNOTES: None.
PiperOrigin-RevId: 160974476
|
|
|
|
| |
PiperOrigin-RevId: 160427360
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
* Replace ```shell with ```sh to fix jekyll build errors
* Fix paths in docgen templates for new docs site directory structure.
* Add jekyll build output directories to gitignore.
RELNOTES: None
PiperOrigin-RevId: 159020213
|
|
|
|
| |
PiperOrigin-RevId: 158428641
|
|
|
|
|
| |
Change-Id: I98fd671af858c402b10bb5ef59735d83d4003593
PiperOrigin-RevId: 157863146
|
|
|
|
| |
PiperOrigin-RevId: 156046860
|
|
|
|
| |
PiperOrigin-RevId: 153531483
|
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 152369293
|
|
|
|
|
|
|
|
| |
(*) instead of using duplicate method names.
(*) Technically it's not a proper method signature since it contains parameter names instead of parameter types.
PiperOrigin-RevId: 152251143
|
|
|
|
|
|
| |
configurable attributes documentation.
PiperOrigin-RevId: 152188409
|
|
|
|
|
|
|
|
| |
Fixes #2270.
--
PiperOrigin-RevId: 150324978
MOS_MIGRATED_REVID=150324978
|
|
|
|
|
|
|
|
| |
displayed properly.
--
PiperOrigin-RevId: 149528271
MOS_MIGRATED_REVID=149528271
|
|
|
|
|
|
|
|
| |
globals.
--
PiperOrigin-RevId: 149286951
MOS_MIGRATED_REVID=149286951
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 149089903
MOS_MIGRATED_REVID=149089903
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 149004753
MOS_MIGRATED_REVID=149004753
|
|
|
|
|
|
|
|
|
|
| |
Skylark modules.
With this change, we no longer have to manually register modules whose generation should be generated. Manual registration turned out to be prone to errors since engineers didn't know about it or simply forgot to register their modules. As a result, we had ~20 modules that featured nice documentation texts, but that were not being picked up by the documentation pipeline.
--
PiperOrigin-RevId: 148136776
MOS_MIGRATED_REVID=148136776
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 147714630
MOS_MIGRATED_REVID=147714630
|
|
|
|
|
|
|
|
|
| |
This improves consistency in the documentation (string and list already
have their own page).
--
PiperOrigin-RevId: 147599068
MOS_MIGRATED_REVID=147599068
|
|
|
|
|
|
|
|
|
| |
It should show up in the documentation in the same way as 'attr', another
builtin module.
--
PiperOrigin-RevId: 147589912
MOS_MIGRATED_REVID=147589912
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 147456653
MOS_MIGRATED_REVID=147456653
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 147384211
MOS_MIGRATED_REVID=147384211
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 144704307
MOS_MIGRATED_REVID=144704307
|
|
|
|
|
|
|
|
| |
* This new configuration allows for passthrough of Swift-specific options into Skylark for further consumption by swift_library. It also keeps things nicely isolated until we get a way to create configurations in Skylark directly.
--
PiperOrigin-RevId: 144210267
MOS_MIGRATED_REVID=144210267
|
|
|
|
|
|
|
|
|
|
| |
solved.
--
Change-Id: Ie9314cabda8b5542979f58cdb2ab7a41e6cd26ad
Reviewed-on: https://cr.bazel.build/8091
PiperOrigin-RevId: 143470985
MOS_MIGRATED_REVID=143470985
|
|
|
|
|
|
|
|
| |
Fixes #1768
--
PiperOrigin-RevId: 142654511
MOS_MIGRATED_REVID=142654511
|
|
|
|
|
|
|
|
| |
It wrongly stated that this only affects the timeout, however it actually affects the resources required for a test to run.
--
PiperOrigin-RevId: 141546278
MOS_MIGRATED_REVID=141546278
|
|
|
|
|
|
|
|
| |
This document states that $(CC) is the "C compiler". This is incomplete and misleading; per comments at line 1799 of CppConfiguration.java, it is expected to be a binary that will compile both C and C++ code.
--
PiperOrigin-RevId: 141459615
MOS_MIGRATED_REVID=141459615
|