| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
| |
--
PiperOrigin-RevId: 150194430
MOS_MIGRATED_REVID=150194430
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 150194302
MOS_MIGRATED_REVID=150194302
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a SpawnAction executes a shell command, we need
to fix PATH on Windows so it starts with
"<msysroot>/bin;<msysroot>/usr/bin", otherwise
bin utils like "find" would be found in the wrong
places, e.g. as "c:/windows/system32/find.exe".
Fixes https://github.com/bazelbuild/bazel/issues/2676
--
PiperOrigin-RevId: 150188402
MOS_MIGRATED_REVID=150188402
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 150187467
MOS_MIGRATED_REVID=150187467
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this way, we can also report the artifacts generated
by aspects in the build event protocol.
For the time being, those events are reported unsolicitly
(i.e., as children of progress events), but they may be linked
to pattern expansion later.
--
Change-Id: I7fb83088d7fdb5424f77bfb78700e8371231b13c
Reviewed-on: https://cr.bazel.build/9370
PiperOrigin-RevId: 150181433
MOS_MIGRATED_REVID=150181433
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 150179734
MOS_MIGRATED_REVID=150179734
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a missing header inclusion to string_win32.c
which was resulting in an implicit function
declaration with the wrong, but compatible type,
causing a char* being converted to int, converted
to char*, corrupting the upper 32 bits, leading to
a segfault.
Fixes https://github.com/bazelbuild/bazel/issues/2672
Change-Id: I805737c93c248f792b2c0f54fe15ab9a261575d2
|
|
|
|
|
|
|
|
| |
RELNOTES: Allow to have several inputs and outputs
--
PiperOrigin-RevId: 150176100
MOS_MIGRATED_REVID=150176100
|
|
|
|
|
|
|
|
|
| |
Closes #2678.
--
Reviewed-on: https://github.com/bazelbuild/bazel/pull/2678
PiperOrigin-RevId: 150167309
MOS_MIGRATED_REVID=150167309
|
|
|
|
|
|
|
|
| |
A previous change added this filegroup with the name %s_files. Recent discussions have suggested changing the naming convention to be a prefix instead before it is too late.
--
PiperOrigin-RevId: 150117207
MOS_MIGRATED_REVID=150117207
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 150100120
MOS_MIGRATED_REVID=150100120
|
|
|
|
|
|
|
|
| |
Only the first target should be cleaned or later incremental build is not incremental.
--
PiperOrigin-RevId: 150096210
MOS_MIGRATED_REVID=150096210
|
|
|
|
|
|
|
|
|
|
|
| |
Add cnsun@ to the list.
Closes #2673.
--
Reviewed-on: https://github.com/bazelbuild/bazel/pull/2673
PiperOrigin-RevId: 150088886
MOS_MIGRATED_REVID=150088886
|
|
|
|
|
|
|
|
| |
annotations.
--
PiperOrigin-RevId: 150088575
MOS_MIGRATED_REVID=150088575
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'blaze query'.
The "streaming" callbacks used by some query functions, e.g. 'deps', make calls to QueryEnvironment#buildTransitiveClosure.
For a cold blaze server, these calls do package loading via LabelVisitor (which calls into Skyframe via a top-level #evaluate call). So we'd prefer a single massive call which can make full use of blaze's loading-phase parallelism via Skyframe over a bunch of sequential small calls.
For a hot blaze server, there are two problems:
(1) LabelVisitor's meager up-to-date check isn't useful (as in we cannot reuse old visitations) when we do a whole bunch of small visitations instead of one massive one.
(2) The actual work of the LabelVisitor (building up a portion of a temporary graph) isn't being effectively parallelized when we do it sequentially in small chunks.
This issue is yet another subtle reason why the old BlazeQueryEnvironment#eval made sense (and why it was unfortunately not compatible with the streaming query evaluation model from the beginning).
--
PiperOrigin-RevId: 150081619
MOS_MIGRATED_REVID=150081619
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically:
1) Read BuildOptions instead of BuildConfiguration
2) Remove unused extra parameters
1) is especially useful for dynamic configs. Before this change, dynamic configs just didn't support attribute configurators. This is because support would require Skyframe-instantiating temporary intermediate configurations, which is horribly awkward and would massively complicate Bazel's dependency evaluation logic. Using BuildOptions instead of BuildConfiguration completely eliminates the problem.
As a bonus, dynamic configs can compose attribute configurators with any other transitions (including splits). This actually makes them more powerful than static configs. Whether anyone wants to use that composition is a different story, but that's now a policy decision vs. a technical limitation. This should also come in handy for RuleClass configurators, which will likely also leverage this.
--
PiperOrigin-RevId: 150080977
MOS_MIGRATED_REVID=150080977
|
|
|
|
|
|
|
|
| |
Iterables.isEmpty winds up expanding the NestedSet, which isn't cheap.
--
PiperOrigin-RevId: 150079225
MOS_MIGRATED_REVID=150079225
|
|
|
|
|
|
|
|
|
|
|
| |
All .dex files to include in the APK must now either be in a zip file or be
named "classes.dex".
Now with test coverage!
--
PiperOrigin-RevId: 150074347
MOS_MIGRATED_REVID=150074347
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix the bug that the MSYS-less client couldn't
connect to the freshly started server and had to
be started again.
Fixes https://github.com/bazelbuild/bazel/issues/2672
See https://github.com/bazelbuild/bazel/issues/2107
--
PiperOrigin-RevId: 150069285
MOS_MIGRATED_REVID=150069285
|
|
|
|
|
|
|
|
| |
--experimental_objc_crosstool=all
--
PiperOrigin-RevId: 150066766
MOS_MIGRATED_REVID=150066766
|
|
|
|
|
|
|
|
| |
This way, we'll eventually get closer to the ideal world where inputs are clearly classified as either mandatory, prunable, discovered or discovered and prunable.
--
PiperOrigin-RevId: 150061912
MOS_MIGRATED_REVID=150061912
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was suggested in the review for unknown commit, which adds ThinLTO support
to another client of CppLinkActionBuilder.
The change required changing the constructor to take a FdoSupportProvider
object instead of a FdoSupport object, so required changes to all callers.
--
PiperOrigin-RevId: 150060046
MOS_MIGRATED_REVID=150060046
|
|
|
|
|
|
|
|
| |
This became necessary because extra actions for C++ compile actions require .h files, but the compiler only returns the .pcm files in the .d file for headers that it reads from the .pcm file. This is not a problem for correctness because the .pcm files depend on the headers, but that doesn't help the extra actions that would then only get the .pcm files.
--
PiperOrigin-RevId: 150052839
MOS_MIGRATED_REVID=150052839
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 150052200
MOS_MIGRATED_REVID=150052200
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix blaze_util_windows::ConvertAbsolutePaths,
which happens to have been the culprit why the
MSYS-less Bazel would always kill the running
server.
Fixes https://github.com/bazelbuild/bazel/issues/2672
See https://github.com/bazelbuild/bazel/issues/2107
--
Change-Id: I873a78c737a6d6906ac7db9bcd0e7186e17bd7ca
Reviewed-on: https://cr.bazel.build/9355
PiperOrigin-RevId: 150052180
MOS_MIGRATED_REVID=150052180
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 150052074
MOS_MIGRATED_REVID=150052074
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 150051360
MOS_MIGRATED_REVID=150051360
|
|
|
|
|
|
|
|
| |
limiting the search to the directory where we expect the file.
--
PiperOrigin-RevId: 150049563
MOS_MIGRATED_REVID=150049563
|
|
|
|
|
|
|
|
|
|
| |
See https://github.com/bazelbuild/bazel/issues/2672
--
Change-Id: Idfbc1841cc4f448939000e58cc9712ab8daa1a2f
Reviewed-on: https://cr.bazel.build/9353
PiperOrigin-RevId: 150045801
MOS_MIGRATED_REVID=150045801
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 150020373
MOS_MIGRATED_REVID=150020373
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 150019741
MOS_MIGRATED_REVID=150019741
|
|
|
|
|
| |
PiperOrigin-RevId: 150019356
MOS_MIGRATED_REVID=150019356
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 150019297
MOS_MIGRATED_REVID=150019297
|
|
|
|
|
|
|
|
|
| |
This is read by PathListConverter which uses java.io.File#pathSeparator which
is already platform-specific.
--
PiperOrigin-RevId: 150008708
MOS_MIGRATED_REVID=150008708
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 149997687
MOS_MIGRATED_REVID=149997687
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 149969486
MOS_MIGRATED_REVID=149969486
|
|
|
|
|
|
|
|
| |
toolchain.
--
PiperOrigin-RevId: 149963021
MOS_MIGRATED_REVID=149963021
|
|
|
|
|
|
|
|
| |
disambiguate the case where the blaze grpc client tells the blaze grpc server to cancel a running command (e.g. the blaze user ctrl+c's the blaze client) between the case a streaming rpc call gets cancelled (e.g. when the grpc client hangs up).
--
PiperOrigin-RevId: 149960615
MOS_MIGRATED_REVID=149960615
|
|
|
|
|
|
|
|
| |
do different (if similar) things and had no common code whatsoever.
--
PiperOrigin-RevId: 149942714
MOS_MIGRATED_REVID=149942714
|
|
|
|
|
|
|
|
| |
Also warn that user values can be lost, at which point later policies won't revive them. This warning should be removed once [] is fixed.
--
PiperOrigin-RevId: 149939586
MOS_MIGRATED_REVID=149939586
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
line. This will be used during development to test new toolchains in docker
containers.
Example usage: --experimental_remote_platform_override='entry:{ name:"a" value:"b" } entry:{ name:"c" value:"d" }'
TESTED=local server
--
PiperOrigin-RevId: 149933081
MOS_MIGRATED_REVID=149933081
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 149930121
MOS_MIGRATED_REVID=149930121
|
|
|
|
|
|
|
|
|
|
| |
as they will not get properly formatted.
See current https://bazel.build/versions/master/docs/skylark/lib/java_common.html
--
PiperOrigin-RevId: 149915047
MOS_MIGRATED_REVID=149915047
|
|
|
|
|
|
|
|
|
|
| |
incremental_install. This is a first step
to add the ability for mobile-install to wait for the debugger before starting the app.
--
PiperOrigin-RevId: 149897848
MOS_MIGRATED_REVID=149897848
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 149813927
MOS_MIGRATED_REVID=149813927
|
|
|
|
|
|
|
|
|
|
| |
by design, the callback passed in there is thread safe. A previous change accidentally introduced this unnecessary synchronization.
Also move SynchronizedBatchCallback to the file with its only current usage.
--
PiperOrigin-RevId: 149809083
MOS_MIGRATED_REVID=149809083
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The error message logged during query (and build) when a package has a
broken Skylark load statement was not specific. Previously, it said
"package contains errors:" and then the package name.
Also, this error message was not emitted when using SkyQueryEnvironment
and evaluating a query containing a "TargetsBelowDirectory" pattern
(such as //foo/...) when a package below the specified directory had
such an error.
The approach taken by this CL is to include any package loading error
message in the SkyValue produced by
CollectPackagesUnderDirectoryFunction, and report them during
evaluation of a TargetsBelowDirectory pattern.
RELNOTES: Evaluation of commands on TargetsBelowDirectory patterns
(e.g. //foo/...) matching packages that fail to load now report more
detailed error messages in keep_going mode.
--
PiperOrigin-RevId: 149802362
MOS_MIGRATED_REVID=149802362
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 149797374
MOS_MIGRATED_REVID=149797374
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 149789440
MOS_MIGRATED_REVID=149789440
|
|
|
|
|
|
|
|
|
|
|
|
| |
Universe evaluation only occurs in the SkyQueryEnvironment
implementation. This setting is a no-op for other QueryEnvironment
implementations.
This support is needed to correctly test an upcoming bugfix.
--
PiperOrigin-RevId: 149786616
MOS_MIGRATED_REVID=149786616
|