| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Error out if the command we try to pass to
CreateProcess is longer than the limit.
Doing so results in a nicer error message than
"The parameter is incorrect" which is confusing.
In this commit I also improve the error reporting
of CreateProcessWithExplicitHandles.
See https://github.com/bazelbuild/bazel/issues/4083
See https://github.com/bazelbuild/bazel/issues/4096
Change-Id: I00ec52238706fd8140483eddb488c3069eaa7814
PiperOrigin-RevId: 175969789
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 175697300
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you have java 9 installed but JAVA_HOME is set to java 8 then some bazel tests will fail because the check for java cannot find rt.jar which no longer exists in java 9.
e.g.
on OSX 10.13
```
> java -version
java version "1.8.0_144"
Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
> JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home bazel test //src/test/py/bazel:action_temp_test
```
will fail with the following
```
FAIL: testLinuxOrDarwinSandboxedBuildAction (__main__.ActionTempTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/private/var/tmp/_bazel_cheister/08d5287ffe0da9d62c01970651a9400e/bazel-sandbox/7165594205799114739/execroot/io_bazel/bazel-out/local-fastbuild/bin/src/test/py/bazel/action_temp_test.runfiles/io_bazel/src/test/py/bazel/action_temp_test.py", line 30, in testLinuxOrDarwinSandboxedBuildAction
self.AssertTempEnvvarWithSpawnStrategy('sandboxed')
File "/private/var/tmp/_bazel_cheister/08d5287ffe0da9d62c01970651a9400e/bazel-sandbox/7165594205799114739/execroot/io_bazel/bazel-out/local-fastbuild/bin/src/test/py/bazel/action_temp_test.runfiles/io_bazel/src/test/py/bazel/action_temp_test.py", line 39, in AssertTempEnvvarWithSpawnStrategy
strategies = self._SpawnStrategies()
File "/private/var/tmp/_bazel_cheister/08d5287ffe0da9d62c01970651a9400e/bazel-sandbox/7165594205799114739/execroot/io_bazel/bazel-out/local-fastbuild/bin/src/test/py/bazel/action_temp_test.runfiles/io_bazel/src/test/py/bazel/action_temp_test.py", line 124, in _SpawnStrategies
self.AssertExitCode(exit_code, 2, stderr)
File "/private/var/tmp/_bazel_cheister/08d5287ffe0da9d62c01970651a9400e/bazel-sandbox/7165594205799114739/execroot/io_bazel/bazel-out/local-fastbuild/bin/src/test/py/bazel/action_temp_test.runfiles/io_bazel/src/test/py/bazel/test_base.py", line 68, in AssertExitCode
'(end stderr)------------------------------------------',
AssertionError: Bazel exited with 1 (expected 2), stderr:
(start stderr)----------------------------------------
INFO: $TEST_TMPDIR defined: output root default is '/private/var/tmp/_bazel_cheister/08d5287ffe0da9d62c01970651a9400e/bazel-sandbox/7165594205799114739/execroot/io_bazel/_tmp/30efe0ec7addffc49fb72b5d5aa45572' and max_idle_secs default is '15'.
Extracting Bazel installation...
Problem with java installation: couldn't find/access rt.jar in /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
(end stderr)------------------------------------------
```
This is related to https://github.com/bazelbuild/bazel/issues/428 but really only fixes the case where you are still using java8 but happen to have java9 installed.
Closes #4045.
PiperOrigin-RevId: 175513188
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|