| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
ToolchainContext configuration earlier.
Change-Id: I034f56a8a181aac19ecb38e51558ccdc6c0c7a6a
PiperOrigin-RevId: 203835978
|
|
|
|
|
|
|
| |
error messaging and commenting when there's an unresolvable skylark type.
RELNOTES: None.
PiperOrigin-RevId: 203826504
|
|
|
|
| |
PiperOrigin-RevId: 203813666
|
|
|
|
| |
PiperOrigin-RevId: 203813658
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dependencies.
This is a reland of https://github.com/bazelbuild/bazel/commit/5deca4cf88f5568771f2c836a9b8c693b88bd749.
This will make protoc see as direct dependencies the .proto files that were included using the proto_source_root flag.
Until now, Bazel passed to protoc the direct dependencies of a target as the path relative to the WORKSPACE, which made it fail when a shorter path, relative to the package was used.
Progress on #4544.
RELNOTES: None.
PiperOrigin-RevId: 203808292
|
|
|
|
|
|
| |
This entails adding equality to all VariableValue subclasses.
PiperOrigin-RevId: 203796225
|
|
|
|
|
|
|
| |
This uses apache velocity engine templates to create markdown-HTML. There are other alternatives, but there is already precedent for depending on this library from docgen.
RELNOTES: None.
PiperOrigin-RevId: 203795431
|
|
|
|
|
|
| |
contribute Make variables.
PiperOrigin-RevId: 203789736
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Follow-up to commit 59f17d6e0550bf63a0b6ef182e2d63474e058ede.
Use try-with-resources to ensure Reader objects
are closed eagerly.
Eagerly closing Readers avoids hanging on to
file handles until the garbage collector finalizes
the object, meaning Bazel on Windows (and
other processes) can delete or mutate these files.
Hopefully this avoids intermittent file deletion
errors that sometimes occur on Windows.
See https://github.com/bazelbuild/bazel/issues/5512
RELNOTES: none
PiperOrigin-RevId: 203771262
|
|
|
|
|
|
|
| |
analysis phase.
RELNOTES: None
PiperOrigin-RevId: 203771085
|
|
|
|
|
|
|
|
|
|
| |
Sources:
https://github.com/bazelbuild/bazel-blog/commit/846478d6943162f4c4d7d50001069e0ca7b2ec28
https://github.com/bazelbuild/bazel-blog/commit/aacaa25314678c08772372b3d46697f7963bb201
RELNOTES: None.
PiperOrigin-RevId: 203763253
|
| |
|
|
|
|
| |
This reverts commit a2cac548616e6e6f433df27146c2971f352a4041.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
library
1. Do not apply /WHOLEARCHIVE to interface library
2. On Windows, we cannot link dll directly, so remove related flag_groups
RELNOTES: None
PiperOrigin-RevId: 203752406
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There can be multiple BuildEventTransports active at
the same time and we need to ensure that each transport
gets its own BuildEventArtifactUploader as these transports
might have different lifecycles.
We do that by introducing another level of indirection via
the BuildEventArtifactUploaderFactory. BlazeModules now
register a factory object instead of an uploader.
In addition, the BuildEventArtifactUploader gets a shutdown()
method that allows to free any resources associated with it.
PiperOrigin-RevId: 203752092
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rewrite the CreateJunction function in the Windows
JNI library.
The new implementation's improvements:
- succeeds if the junction already exists with the
desired target; hopefully this will fix issue
https://github.com/bazelbuild/bazel/issues/5433
- tolerant to concurrent filesystem modifications,
e.g. if the junction's path suddenly disappears,
the function reports the error correctly
Fixes https://github.com/bazelbuild/bazel/issues/5433
Change-Id: I58a2314a00f6edaa7c36c35ba54616168b44eb7d
Closes #5528.
Change-Id: I9f5dc9237b70a433d0d8c2578a826de3d462d110
PiperOrigin-RevId: 203744515
|
|
|
|
|
|
|
| |
Also add preconditions check.
RELNOTES: None.
PiperOrigin-RevId: 203731929
|
|
|
|
|
|
|
| |
It was used in a single, Google-internal test which I cleaned up as pre-work for this change.
RELNOTES: None.
PiperOrigin-RevId: 203727293
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is a fundamental bottleneck in the way targets are currently configured:
The ConfiguredTargetFunction needs to load all dependent targets before it can
configure its own target. Now, outgoing deps of a target can be in three
states:
1. Package of dependency target not yet loaded
2. Dependency target not configured, but package already loaded
3. Dependency target configured
State #3 is good, we don't need to do any more work before we can configure the
current target. Now, most targets will have a combination of deps in states #1
and #2. The current behavior is to schedule the target configuration of deps in
state #2 and the package loading in state #1 (to get to state #3 and #2,
respectively). Only after *all* of these are computed will the corresponding
ConfiguredTargetFunction be rescheduled upon which the remaining deps that were
in state #1 before are now in state #2 and the corresponding target
configuration can be started.
This creates a substantial parallelization bottleneck by artifically sync'ing
the state transitions (#1->#2 and #2->#3) for all deps. In turn, this makes the
critical path artifically long. Instead, settle for just loading dependent
packages as long as there are any. This is a fast single-step operation.
Postpone the configuration of dependent targets to later as it can require long
dependency chains to be configured.
In theory, a better solution would be to split the target configuration in a
way so that it is possible to ask for configured targets without yet knowing
their package. However, that would require pulling config transitions apart (as
some of them happen because of the origin target/config and some of them happen
because of the destination target. Thus we'd need to change the
ConfiguredTargetKey so that the configuration stands for the configuration that
we request the target in, with target-caused transitions already applied. Now
that itself leads to inefficiencies. E.g. we would start requestiong InputFiles
in several configurations just to underneath always load them with a null
configuration.
RELNOTES: Faster analysis by improved parallelization.
PiperOrigin-RevId: 203725209
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
JavaIoFileSystem.delete() now uses
Files.deleteIfExists() to delete files and empty
directories.
The old code used to have a race condition: a
file could have been deleted or changed to a
non-directory between checking it's a directory
and listing its contents.
WindowsFileSystem.delete() now uses the
DeletePath JNI method (wrapped by
WindowsFileOperations.deletePath) which is more
robust than JavaIoFileSystem.delete(), because it
can delete readonly files and can tolerate some
concurrent filesystem modifications.
Fixes https://github.com/bazelbuild/bazel/issues/5513
Change-Id: I5d2720afff8dfd3725880a6d7408d22de5935c3d
Closes #5527.
Change-Id: I5d2720afff8dfd3725880a6d7408d22de5935c3d
PiperOrigin-RevId: 203720575
|
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 203720055
|
| |
|
|
|
|
|
|
| |
instead of indirecting through the toolchain's compatible_javacopts.
PiperOrigin-RevId: 203502116
|
|
|
|
|
|
|
| |
This metric measures the used heap size at the end of the build, after a GC. Because this is expensive it is only collected if a flag is passed.
RELNOTES:
PiperOrigin-RevId: 203492365
|
|
|
|
|
| |
RELNOTES: [JavaInfo] Outputs are merged in java_common.merge().
PiperOrigin-RevId: 203474741
|
|
|
|
|
|
|
|
|
|
|
| |
The only reason that those python wrapper scripts still exists is for
TensorFlow's Windows GPU build. As we will create a custom GPU CROSSTOOL
in TF repo, we can finally remove wrapper scripts from Bazel.
Closes #5526.
RELNOTES: Python wrapper scripts for MSVC are removed.
PiperOrigin-RevId: 203472223
|
|
|
|
|
|
|
| |
It's no longer needed.
RELNOTES: None.
PiperOrigin-RevId: 203469119
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 203466429
|
|
|
|
|
|
|
|
|
|
| |
In this way, their name is one they can actually be referred to by.
This is necessary, as Skylark repository rules end up in the resolved
file when freezing the versions of external dependencies---and the call
to the repository function might be indirect.
Change-Id: Ie1b5a28fac4f690c424de848b42d0c4a217d494d
PiperOrigin-RevId: 203466286
|
|
|
|
|
|
|
| |
want to use input discovery when building modules for performance reasons.
RELNOTES: None.
PiperOrigin-RevId: 203463009
|
|
|
|
| |
PiperOrigin-RevId: 203461813
|
|
|
|
|
|
|
|
|
|
|
| |
building with C++ modules, .d file scanning is not effective as Clang (only
compiler supporting Bazel's version of C++ modules) reads all of the files
passed in anyway.
This is not meant to be activated yet, but for running experiments.
RELNOTES: None.
PiperOrigin-RevId: 203459168
|
|
|
|
|
|
|
|
|
|
|
| |
Commit d3f7f7ae introduced a bug in the FileTransport implementations
where events might not be written to file in the correct order. This
change fixes this.
Fixes #5515
RELNOTES: None
PiperOrigin-RevId: 203457636
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 203454741
|
|
|
|
|
|
|
| |
modules.
RELNOTES: None.
PiperOrigin-RevId: 203454562
|
|
|
|
|
|
|
| |
Fixes #5246
RELNOTES: None.
PiperOrigin-RevId: 203453340
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement a native DeletePath method that can
delete files, directories, and junctions. The
method should tolerate when concurrent
processes delete the file.
The new JNI function is more robust than Java IO
file deletion function because it can also delete
readonly files.
See https://github.com/bazelbuild/bazel/issues/5513
Closes #5520.
Change-Id: I21ea36dd64960b294e2b51600273bf4290ad7c0f
PiperOrigin-RevId: 203448581
|
|
|
|
|
|
|
| |
Fix https://github.com/bazelbuild/bazel/issues/5516
RELNOTES: None
PiperOrigin-RevId: 203448188
|
|
|
|
|
|
|
|
|
|
|
| |
...as this file uses blaze_util::JoinPath. Apparently, until
recently, that header file was pulled in indirectly, so that
this wasn't detected until now. Nevertheless, the header files
for functions used directly should also be included explicitly
anyway.
Change-Id: Id181480c6ec7fd146ce8b7b00980319f13c3f518
PiperOrigin-RevId: 203445044
|
|
|
|
|
|
|
| |
PiperOrigin-RevId: 203300374
Change-Id: Iaa47f870ab2e0cad40a202aad2c7f9430f73c856
PiperOrigin-RevId: 203407392
|
|
|
|
|
|
|
|
| |
java_toolchain.package_configuration javacopts
to allow package_configuration to override compatible_with javacopts.
PiperOrigin-RevId: 203396587
|
|
|
|
|
| |
RELNOTES: Remove support for java_runtime_suite; use alias() together with select() instead.
PiperOrigin-RevId: 203393253
|
|
|
|
|
|
|
|
|
|
| |
So far, bazel sync would only report error that happened during
the actual fetch operation. However, errors can also happen earlier,
e.g., when loading or parsing the WORKSPACE file. Report these
errors as well.
Change-Id: Ifa4961b0101f338d7618c52eb607951acba7ccdf
PiperOrigin-RevId: 203359188
|
| |
|
|
|
|
|
|
|
|
|
|
| |
On some systems (including some versions of FreeBSD) it is a requirement
that _WITH_DPRINTF be defined for <stdio.h> to provide the appropriate
header for dprintf(3). Therefore, the respective #define has to come
before any #include as those might pull is <stdio.h>.
Change-Id: I25d55c9c7c0912e8619faf774d2e09f9af9a6a53
PiperOrigin-RevId: 203351202
|
|
|
|
|
|
|
|
|
|
|
| |
It's no longer fatal for the test if $JAVA_HOME
environment variable is unset.
Before this fix the test was crashing if JAVA_HOME
was not set.
RELNOTES: none
PiperOrigin-RevId: 203350738
|
|
|
|
|
|
|
|
|
|
|
| |
Use the "with" statement to open files in various
Python scripts used by Bazel, to ensure these
files are closed eagerly.
See https://github.com/bazelbuild/bazel/issues/5512
RELNOTES: none
PiperOrigin-RevId: 203346678
|
|
|
|
|
|
|
| |
Before this cl the sysroot variable was not present, and that's a bug.
RELNOTES: None
PiperOrigin-RevId: 203346557
|
|
|
|
|
|
| |
Fixes #5469
PiperOrigin-RevId: 203343005
|