| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
Configs are recursive, but let's be reasonable. If there's an absurdly long list of configs inheritance, warn about it. It is probably unnecessary, and might very well be unintentional and surprising to the user.
RELNOTES: None.
PiperOrigin-RevId: 176405183
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `set` constructor used to be deprecated, but it was still possible to use
it by providing --incompatible_disallow_set_constructor=false.
It's still allowed to have `set` in parts of the code that are not executed, this will be deprecated later.
RELNOTES[INC]: The deprecated `set` constructor is removed, along with the
migration flag --incompatible_disallow_set_constructor. It is still temporarily
allowed to refer to `set` from within unexecuted code.
PiperOrigin-RevId: 176375859
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--expand_configs_in_place.
--config options were expanded in a fix-point expansion, where in practice, the flags that --config values expanded to ended up between the normal bazelrc options and the command line's explicit options. Since the options parser has an order-based priority scheme and it accepts multiple mentions of a single-valued option, this conflicts with users' expectations of being able to override these config expansions by using the order in which they are mentioned.
This change makes it possible to expand the config values defined in your bazelrc (or blazerc) files to occur in-place: --stuff --config=something --laterstuff will interpret the options that --config=something expands to as if they had been mentioned explicitly between --stuff and --laterstuff.
In order to not break users relying on complex flag combinations to configure their builds, this behavior will not yet be turned on by default. Instead, use --expand_configs_in_place as a startup flag to test this feature. --announce_rc may be helpful for debugging any differences between the fixed point and in-place expansions. Once you've debugged your problems, add "startup --expand_configs_in_place" to your blazerc to stick to the new behavior.
RELNOTES: Use --expand_configs_in_place as a startup argument to change the order in which --config expansions are interpreted.
PiperOrigin-RevId: 176371289
|
|
|
|
|
|
|
| |
https://github.com/bazelbuild/bazel/issues/3985
Change-Id: Ib566103e147219122b3f745a98ad30db5f27553f
PiperOrigin-RevId: 176365079
|
|
|
|
|
|
|
|
|
| |
repository.
Part of #4056.
Change-Id: I4b8e41660b0a135e23aa572bbfeea27a7cda0581
PiperOrigin-RevId: 176362103
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Fix for #4035
@laszlocsomor
Closes #4110.
PiperOrigin-RevId: 176346381
|
|
|
|
|
|
|
|
| |
platform-based toolchain selection to match legacy behavior.
This is a change over previous behavior in the platform case, which was to throw if either of those attributes is not present. The default_toolchain field in CROSSTOOL gives a mapping from cc_toolchain.cpu values to toolchains - this map should be used with compiler and libc are not specified, as is currently the non-platforms, legacy behavior.
PiperOrigin-RevId: 176246316
|
|
|
|
|
|
|
|
| |
Notable implementation details:
- split the flag into --experimental_post_build_query and --experimental_query_options
- allow --nohost_dep filtering to be applied to query targets configured in the host configuration (only returns deps also in the host configuration so allow deps as long as it never sees a transition from a host config to a non-host config)
PiperOrigin-RevId: 176165870
|
|
|
|
|
|
|
|
| |
Add reference to strip-prefix with a real-world example of usage.
Closes #3969.
PiperOrigin-RevId: 176151504
|
|
|
|
|
|
| |
ToolchainInfo.
PiperOrigin-RevId: 176117866
|
|
|
|
|
|
|
|
| |
Designed by
https://docs.google.com/document/d/1hK2mWl3TYNL9oJYX_S020TKkXZvBw1aBoYERvTHVyfg/edit#
Change-Id: I025adf555a9827c55a90acc3f254cbd105e224c6
PiperOrigin-RevId: 176114968
|
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 176109497
|
|
|
|
|
|
|
|
| |
This will avoid the uninformative NullPointerException for this case (#3913). The underlying cause is data dependency on directories, which we want to disable. In the future, it will be allowed, but in a more explicit form (e.g. trailing slash).
TESTED=no
RELNOTES: None
PiperOrigin-RevId: 176109375
|
|
|
|
|
| |
Change-Id: I28eee0bfdcdfc832c44a7a0af4d3c6f443e39a17
PiperOrigin-RevId: 176092054
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 176085426
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 176025413
|
|
|
|
| |
PiperOrigin-RevId: 176006176
|
|
|
|
|
|
| |
Fixes #1479.
PiperOrigin-RevId: 175979487
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also, add a fake databinding processor target.
Bazel users will need to do something like this:
# WORKSPACE
local_repository(
name = "databinding",
path = "./databinding",
)
bind(
name = "databinding_annotation_processor",
actual = "@databinding//:annotation_processor",
)
# databinding/BUILD
java_plugin(
name = "annotation_processor",
...
)
...
https://github.com/bazelbuild/bazel/issues/2694
RELNOTES: None
PiperOrigin-RevId: 175975110
|
|
|
|
|
|
|
|
|
|
| |
Bazel used to fail the entire build if there is a single error with remote
spawn cache. This could happen on unreliable network or when server is under
load. This change will allow Bazel to fallback to local execution with a
warning.
Change-Id: I0bd41dc862b33a2ab2ab772d8ce9c943476edbf4
PiperOrigin-RevId: 175951699
|
|
|
|
|
|
|
| |
This is not used by ASwB, and it also doesn't make sense to live in AndroidBinary since android_binary does nothing with it's data deps and they should be removed (b/69371443).
RELNOTES: None
PiperOrigin-RevId: 175877850
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 175866310
|
|
|
|
| |
PiperOrigin-RevId: 175838317
|
|
|
|
| |
PiperOrigin-RevId: 175832159
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Causing Bazel server to crash when running bazel clean --expunge
https://github.com/bazelbuild/bazel/issues/3956
*** Original change description ***
Delayed rollforward of commit 8fb311b4dced234b2f799c16c7d08148619f4087.
This was rolled back due to Tensorflow breakage but the patch I exported to gerrit (https://bazel-review.googlesource.com/c/bazel/+/18590) passed Tensorflow (https://ci.bazel.io/job/bazel/job/presubmit/52/Downstream_projects/). Confirmed with jcater@ that the "newly failing" projects in the Global Tests are known issues. I think we can check this in now.
Additionally I had attempted to reproduce any tensorflow issues with this by building and testing Tensor...
***
ROLLBACK_OF=172361085
RELNOTES:None
PiperOrigin-RevId: 175821671
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even if an action is planned to run and a strategy assigned,
it does not mean it is actually executing; e.g., it might be
waiting for local resources. To reduce confusion, show the
status instead of the execution strategy for non-executing
actions. Also avoid the word "running" for the total number
of executing and scheduled to be executed actions.
Improves on Issue #4089.
Change-Id: If658c1a24ee26eb27ccd892847af18015355a8d3
PiperOrigin-RevId: 175818071
|
|
|
|
|
| |
Change-Id: If8f4c75b65d5654703a68fe70277dc597773c85d
PiperOrigin-RevId: 175737062
|
|
|
|
|
|
| |
Closes #3972.
PiperOrigin-RevId: 175726041
|
|
|
|
|
|
|
|
|
| |
This is some clean up pulled out of unknown commit. It avoids needing
to reconstruct the dwoFile, which will be harder when we move to
using shared LTO backends in some cases.
RELNOTES: None
PiperOrigin-RevId: 175692708
|
|
|
|
| |
PiperOrigin-RevId: 175682806
|
|
|
|
|
|
|
|
|
|
|
| |
Quote empty args in the command argument vector
otherwise the command's executable would not
recognize them as arguments.
Fixes https://github.com/bazelbuild/bazel/issues/3973
Change-Id: Iccfb59e75c748247c8df7d52fb8cf4227eae6fa7
PiperOrigin-RevId: 175672201
|
|
|
|
|
|
|
|
| |
RELNOTES[NEW]: Users can use win_def_file attribute to specify a DEF file for
exporting symbols when build a shared library on Windows.
Change-Id: Ifa28d8b7b24eaefcefc9640d8dc56fd2931e9688
PiperOrigin-RevId: 175651203
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks Google-internal targets, sadly.
*** Original change description ***
Ban middlemen from runfiles artifacts.
Previous changes have removed all middlemen from runfiles
artifacts. This CL locks it down and removes various now-redundant
*WithoutMiddlemen() methods from Runfiles.
I put a check for middlemen in ConflictChecker.put, which should be a
chokepoint for runfiles artifacts. It's unfortunate we can't detect
middlemen earlier than execution, but I can't see a way to efficiently
check every runfiles artifact earlier.
Cha...
***
RELNOTES: None.
PiperOrigin-RevId: 175650018
|
|
|
|
|
|
|
|
| |
For build log files that are inlined, we eventually have to
report ByteStrings, so avoid the detour through strings,
potentially causing encoding issues.
PiperOrigin-RevId: 175647576
|
|
|
|
| |
PiperOrigin-RevId: 175630707
|
|
|
|
|
|
|
| |
GITHUB: #903
RELNOTES: None.
PiperOrigin-RevId: 175600267
|
|
|
|
|
|
|
| |
incorrectly using multi-arch iOS
RELNOTES: None.
PiperOrigin-RevId: 175579695
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 175576296
|
|
|
|
| |
PiperOrigin-RevId: 175558546
|
|
|
|
| |
PiperOrigin-RevId: 175535010
|
|
|
|
|
|
| |
configuration.
PiperOrigin-RevId: 175532550
|
|
|
|
| |
PiperOrigin-RevId: 175531318
|
|
|
|
|
|
|
|
|
|
| |
runs_per_test allows multiple argument instances, because there's an
option of using a per-label regex format.
Unlike most such flags, earlier instances of the flag were dominating
later ones.
PiperOrigin-RevId: 175530675
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
It was added long ago, for reasons which are no longer relevant or
useful.
Also remove the build variable it controlled ("skip_mostly_static")
from CROSSTOOL files.
RELNOTES: None.
PiperOrigin-RevId: 175325225
|
|
|
|
|
|
| |
on a graph without edges. Now we fail gracefully.
PiperOrigin-RevId: 175294923
|
|
|
|
|
|
|
| |
Accept warnings specified by flag. This flag will cause a warning to be printed like a standard Option deprecation warning or any other warning from options parsing. This can be used to deprecate definitions of config expansion or bazelrc files. This should not be used to deprecate internal option specifications.
RELNOTES: None.
PiperOrigin-RevId: 175231963
|
|
|
|
| |
PiperOrigin-RevId: 175230893
|
|
|
|
|
|
| |
instead of assuming it is a deploy jar.
PiperOrigin-RevId: 175229774
|