| Commit message (Collapse) | Author | Age |
|
|
|
| |
PiperOrigin-RevId: 184913521
|
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 184909685
|
|
|
|
|
|
|
|
| |
CcToolchainFeatures.Variables.
We rephrase the nocopts filter from a Predicate<String> to a custom class, since AutoCodec cannot serialize a Predicate.
PiperOrigin-RevId: 184902162
|
|
|
|
| |
PiperOrigin-RevId: 184889583
|
|
|
|
|
|
|
| |
them with getConfiguredTargetAndTarget() so we can get rid of
ConfiguredTarget.getTarget() callers. This should be a test only change.
PiperOrigin-RevId: 184877255
|
|
|
|
|
|
|
|
|
|
|
|
| |
to be the other way around).
This fixes b/72817591 which saw the following -
(1) somepath(//foo, //bar) --nohost_deps -> empty query results
(2) deps(//foo) --nohost_deps | grep '//bar' -> found //bar
This happened because //bar was configured in both the host and the target config. There was no path from //foo-target -> //bar-host because of the --nohost_deps setting (1) but //bar-target did exist in the results of (2)
PiperOrigin-RevId: 184868484
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 184865343
|
|
|
|
| |
PiperOrigin-RevId: 184862552
|
|
|
|
|
|
|
|
| |
Suggestion from @angersson on GitHub: https://github.com/bazelbuild/bazel/issues/4068#issuecomment-347627252
GITHUB: https://github.com/bazelbuild/bazel/issues/4068
RELNOTES: Improved clarity of warning message for unsupported NDK revisions.
PiperOrigin-RevId: 184852316
|
|
|
|
|
|
|
| |
no-op behavior-wise.
RELNOTES: None
PiperOrigin-RevId: 184843442
|
|
|
|
|
|
|
|
|
|
| |
Ensure that each test attempt is only reported after the report of the
completion of the build of the corresponding test target. Normally this
should happen anyway, but due to races on the internal event bus, the
order of the report might be messed up. So add an explicit order constraint.
Change-Id: I4d325bc31a46dcdf8763ba5416b5135a0978536e
PiperOrigin-RevId: 184825306
|
|
|
|
| |
PiperOrigin-RevId: 184784669
|
|
|
|
|
|
|
|
| |
required in order to serialize CppCompileAction.
Rephrase CppCompilationContext's pregreppedHeaders field as its own value class instead of Pair<Artifact, Artifact>. We do this because NestedSet support in AutoCodec cannot serialize a NestedSet of a generic type.
PiperOrigin-RevId: 184740075
|
|
|
|
| |
PiperOrigin-RevId: 184734801
|
| |
|
|
|
|
|
|
|
|
|
|
| |
define a binary_under_test.
They are filtered out for deployment anyways so it's unnecessary work and it
confuses the one version detector.
RELNOTES: n/a
PiperOrigin-RevId: 184725205
|
|
|
|
|
|
|
|
|
|
|
|
| |
Filtering only in analysis was neglecting the possibility of resources being in
filesets, the contents of which are not available in analysis. As such, we must
*always* filter in execution, even though it's usually just going to be a
no-op.
Also, add some documentation of same.
RELNOTES: none
PiperOrigin-RevId: 184722564
|
|
|
|
| |
PiperOrigin-RevId: 184720361
|
|
|
|
| |
PiperOrigin-RevId: 184710375
|
|
|
|
|
|
|
|
|
| |
execution platforms.
Part of #4442.
Change-Id: I6678d57f4aaadcb19032bf58820606242ba66a25
PiperOrigin-RevId: 184707708
|
|
|
|
|
|
| |
Looks like this got missed.
PiperOrigin-RevId: 184701334
|
|
|
|
|
|
|
| |
file.
Change-Id: I5b66b91f016e12e546600f585546fc56d9511303
PiperOrigin-RevId: 184698749
|
|
|
|
|
|
|
|
|
| |
We apparently don't have any other implementations of these interfaces than
BlazeCommandDispatcher, so let's not have them at all; we can always put back
an interface with the exec() method if need be.
RELNOTES: None.
PiperOrigin-RevId: 184698573
|
|
|
|
|
|
| |
field type information.
PiperOrigin-RevId: 184695891
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 184692000
|
|
|
|
| |
PiperOrigin-RevId: 184689620
|
|
|
|
|
|
| |
runtime check on the type of the iterable, performing custom serialization for a NestedSet.
PiperOrigin-RevId: 184686288
|
|
|
|
|
|
|
|
|
| |
This can be encapsulated in a device script fixture as an environment variable.
https://developer.android.com/studio/command-line/logcat.html#filteringOutput
RELNOTES: None.
PiperOrigin-RevId: 184683289
|
|
|
|
|
|
|
| |
should be shut down in BlazeCommandResult.
RELNOTES: None.
PiperOrigin-RevId: 184678994
|
|
|
|
|
|
|
| |
Part of #4442.
Change-Id: I21baffe59431ccd3d76754596ec2a605dbbe4354
PiperOrigin-RevId: 184678470
|
|
|
|
|
|
|
| |
This is the second try for this CL. The first one caused Blaze to crash when building Exoblaze as shown in b/72936965. In this CL I fix the condition of when to generate non-PIC compilation actions for WrapCcHelper.
RELNOTES:none
PiperOrigin-RevId: 184671661
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Try again with fixes.
*** Original change description ***
Automated rollback of commit 10b0d8aa6b73a024cc007c5e075cb329add878ef.
*** 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 arti...
***
PiperOrigin-RevId: 184661375
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 184649483
|
|
|
|
|
|
| |
InjectingObjectCodec.
PiperOrigin-RevId: 184566571
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
native skyframe implementation was actually quite incorrect in this case: It was adding a skyframe dependency on a FileValue for the output file. Without a transitive dependency on the source files and actions that determine the output file's state, this could never work (and explains why the incremental build would fail). Instead, we now depend on the Artifact corresponding to the output file instead.
This change updates the business logic RecursiveFilesystemTraversalFunction. This approach keeps the business logic of Fileset filesystem traversal centralized in RFTF.
To avoid making weird recursive Skyframe nodes in the output tree, we inline Skyframe dependencies and do direct filesystem operations over the output tree.
There are now three states we can be in when looking up a file:
1. Source file: As before, make a skyframe dep on the corresponding file
2. Top-level file of an output tree: Make a dep on the corresponding Artifact
3. Recursive file under an output directory: Do direct filesystem operations. It doesn't make sense to make Skyframe nodes corresponding to these files. In the future, I think we should consider failing fast on this case.
RELNOTES: None
PiperOrigin-RevId: 184556044
|
|
|
|
|
|
| |
since it's never instantiated on its own.
PiperOrigin-RevId: 184554483
|
|
|
|
|
|
|
|
| |
essentially promote OwnedArtifact to ArtifactSkyKey and rename it to ArtifactSkyKey. The king is dead...
Also add some other execution-phase codecs.
PiperOrigin-RevId: 184552706
|
|
|
|
| |
PiperOrigin-RevId: 184540561
|
|
|
|
|
|
|
|
|
|
|
| |
the runfiles tree.
As I understand it, this is only a theoretical issue today because
$unified_launcher is generally a flat file. (Flat files never have
runfiles middlemen.) However, it's good to be future proof.
Change-Id: If77edfa9dd7475ab93b19c62b08f8d86a77acbe6
PiperOrigin-RevId: 184540188
|
|
|
|
|
|
| |
SpecialArtifact.
PiperOrigin-RevId: 184539696
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 184538771
|
|
|
|
|
|
|
|
| |
We're now using ctime to detect file changes, so the timestamp granularity monitor should as well.
Unfortunately, we currently get nanosecond ctime from Linux, but then only return millis from FileStatus, so this doesn't change the accuracy of the monitor at all.
PiperOrigin-RevId: 184536539
|
|
|
|
|
|
|
| |
rule for the execution statistics path.
RELNOTES: None.
PiperOrigin-RevId: 184534589
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
child of the process where the Blaze client itself was run.
Limitations:
- Untested on Windows; it should work because ExecuteProgram() is implemented there, too, but since Windows doesn't support exec(), there is at least one process in between
Progress towards #2815.
RELNOTES[NEW]: The new "--direct_run" flag on "blaze run" lets one run interactive binaries.
PiperOrigin-RevId: 184528845
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Causes Blaze to crash when building Exoblaze as shown in b/72936965.
Confirmed as root cause by rolling back this CL, building a Blaze
from HEAD, and successfully using it to build Exoblaze.
*** Original change description ***
C++: Remove last instatiation of CppModel outside CcLibraryHelper.
RELNOTES:none
PiperOrigin-RevId: 184528551
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 184518931
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also update the Python stub script template to set
$RUNFILES_MANIFEST_FILE or $RUNFILES_DIR so the
runfiles library only needs to look for those.
See https://github.com/bazelbuild/bazel/issues/4460
RELNOTES[NEW]: python,runfiles: You can now depend on `@bazel_tools//tools/runfiles:py-runfiles` to get a platform-independent runfiles library for Python. See DocString of https://github.com/bazelbuild/bazel/blob/master/src/tools/runfiles/runfiles.py for usage information.
Change-Id: I4f68a11cb59f2782e5203e39fe60cc66b46023a2
PiperOrigin-RevId: 184515490
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 184510731
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 184498836
|