| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
b/78577719
*** Original change description ***
Change action construction to use built-in param file support.
We want to be able to control how and when param files are used, and manual construction of param files prevents this. It should also be less code overall.
For this CL, when param files are used is unchanged, their format and encoding is unchanged. The flag name is also unchanged, except in some cases it was changed from (eg.) "--flagfile foo" to "--flagfile=foo".
However, the name of the param file is now derived from the primary...
***
RELNOTES: None
PiperOrigin-RevId: 194389749
|
|
|
|
| |
PiperOrigin-RevId: 194387085
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
skylark
This cl enabled skylark rules to compute the command line using feature
configuration, the same mechanism that native C++ rules use.
Working towards #4571.
RELNOTES: CppRules: C++ command lines and env variables for C++ actions can be
retrieved from feature configuration.
PiperOrigin-RevId: 194384637
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In StandaloneTestStrategy, copy as much information as SpawnResult makes
available to us through to both the TestResultData and BEP's
TestResult.ExecutionInfo protos. One immediate consequence is that the UI and
BEP can tell you whether a test result was cached remotely.
I changed Executor.getEventHandler to return an ExtendedEventHandler because it
makes this change easier to test.
Closes #5081.
Change-Id: I94fefdcd2e029c81085076736ad13a4bdf1bae8f
PiperOrigin-RevId: 194383009
|
|
|
|
|
|
|
|
|
| |
Rule authors frequently wants to make assertions on the parameter files their rule implementations have created. However, if they do not explicitly create parameter file write actions, or if indeed _there aren't_ any parameter file write actions inserted into the action graph, the tests will fail.
This CL adds necessary methods for the migration.
RELNOTES: None
PiperOrigin-RevId: 194379748
|
|
|
|
|
|
|
| |
additional compiler options.
RELNOTES: None.
PiperOrigin-RevId: 194363080
|
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 194353580
|
|
|
|
|
|
| |
instead of one boolean each to save a byte in the encoded stream.
PiperOrigin-RevId: 194280646
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Design doc: https://docs.google.com/document/d/1JXqwwVHYosZOgmjN8xrfTalyhiUYJ99Qe2D0qBcqZ1c
The behaviour is gated on --defer_param_files (default off) and is controlled by --min_param_file_size.
This CL adds support for VirtualActionInputs to LocalSpawnRunner, and all remote runners already supports them. The sandboxed runners are not yet supported, but that can be added in a future CL.
This CL does not add support for spawn runner using different param file limits. This will require refactoring of the spawn strategies and runners to be viable.
RELNOTES: None
PiperOrigin-RevId: 194265291
|
|
|
|
|
|
|
|
|
|
|
| |
Compilations performed by java_common.compile now use the javacopts in the
java_toolchain by default, instead of requiring them to be explicitly retrived
using java_common.default_javac_opts, for consistency with the native rules.
java_common.compile(javac_opts=...) can still be used to pass additional javacopts.
RELNOTES: Make java_common.compile now uses java_toolchain javacopts by default; explicitly retrieving them using java_common.default_javac_opts is unnecessary.
PiperOrigin-RevId: 194254098
|
|
|
|
| |
PiperOrigin-RevId: 194236287
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 194236052
|
|
|
|
| |
PiperOrigin-RevId: 194232982
|
|
|
|
|
|
|
| |
additional compiler options.
RELNOTES: None.
PiperOrigin-RevId: 194232650
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Turns out the "unique" id returned by SpawnExecutionContext is only
unique within one SpawnRunner, but not across multiple SpawnRunner
classes.
We have to prefix the generated path with the name of the current
strategy in order to not run into conflicts when a build happens to use
multiple different sandbox strategies.
RELNOTES: None.
PiperOrigin-RevId: 194230475
|
|
|
|
|
|
|
|
|
| |
files
This change is due to Windows and macOS, where file paths are case-insensitive
RELNOTES:
PiperOrigin-RevId: 194223755
|
|
|
|
|
|
|
| |
WithFeatureSet class
RELNOTES: None.
PiperOrigin-RevId: 194218956
|
|
|
|
|
|
|
| |
Moving CompilationSupport out of for loop. All generated object-c files will be compiled in one CompilationHelper, which avoids object file path conflicts.
RELNOTES: None
PiperOrigin-RevId: 194215804
|
|
|
|
|
|
|
|
|
|
|
| |
We want to be able to control how and when param files are used, and manual construction of param files prevents this. It should also be less code overall.
For this CL, when param files are used is unchanged, their format and encoding is unchanged. The flag name is also unchanged, except in some cases it was changed from (eg.) "--flagfile foo" to "--flagfile=foo".
However, the name of the param file is now derived from the primary output of the action (instead of manually controlled).
RELNOTES: None
PiperOrigin-RevId: 194209601
|
|
|
|
|
|
|
|
|
|
|
| |
We want to be able to control how and when param files are used, and manual construction of param files prevents this. It should also be less code overall.
For this CL, when param files are used is unchanged, their format and encoding is unchanged. The flag name is also unchanged, except in some cases it was changed from (eg.) "--flagfile foo" to "--flagfile=foo".
However, the name of the param file is now derived from the primary output of the action (instead of manually controlled).
RELNOTES: None
PiperOrigin-RevId: 194208049
|
|
|
|
|
|
|
|
|
|
|
|
| |
When completing the build and doing the final flush of the
incomplete stdout/stderr lines, remove any existing progress
bar first (and redraw afterwards) to avoid interference.
Also, upon receiving the AfterCommandEvent, just call
completeBuild instead of trying to do the same manually
again.
Change-Id: If375be798a5e66558676f0ffb845fb64279584f8
PiperOrigin-RevId: 194203925
|
|
|
|
| |
PiperOrigin-RevId: 194191933
|
|
|
|
|
|
|
| |
This is needed for constructors that want to be able to use SkylarkSemantics.
RELNOTES: None
PiperOrigin-RevId: 194180124
|
|
|
|
|
|
|
|
|
|
|
| |
as a normal feature.
Prior to this cl, it was always set by examining
supports_embedded_runtimes.
DELTA_BY_EXTENSION=java=100,py=15
RELNOTES: None
PiperOrigin-RevId: 194172053
|
|
|
|
|
|
|
|
|
|
|
| |
We want to be able to control how and when param files are used, and manual construction of param files prevents this. It should also be less code overall.
For this CL, when param files are used is unchanged, their format and encoding is unchanged. The flag name is also unchanged, except in some cases it was changed from (eg.) "--flagfile foo" to "--flagfile=foo".
However, the name of the param file is now derived from the primary output of the action (instead of manually controlled).
RELNOTES: None
PiperOrigin-RevId: 194171911
|
|
|
|
| |
PiperOrigin-RevId: 194170571
|
|
|
|
|
|
|
|
| |
Looks like a typo resulted in getSlowestTasks accumulating way more than it
should have and we were missing the test coverage to catch it.
RELNOTES: None
PiperOrigin-RevId: 194169355
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL includes the rollback + better fix for issue #4922.
https://github.com/bazelbuild/bazel/issues/4922
*** Reason for rollback ***
Breaks mobile-install v2 adb port forwarding, b/78432638
*** Original change description ***
Fix crash from mobile-install with --device but no --adb_args.
Fixes #4922.
RELNOTES: None
PiperOrigin-RevId: 194155557
|
|
|
|
| |
PiperOrigin-RevId: 194151342
|
|
|
|
| |
PiperOrigin-RevId: 194138150
|
|
|
|
|
|
| |
constructing JavaInfo providers instead
PiperOrigin-RevId: 194123199
|
|
|
|
|
|
|
|
|
|
|
|
| |
Design: https://docs.google.com/document/d/1ubah6phuvWnugShtVgSQnaopQ1BtKtNxQASVwGZA7k0/
* Moves action construction out into java_common.run_ijar, java_common.pack_sources
* Deprecates corresponding arguments in JavaInfo
An incompatible flag will be added in another CL since it is not possible to add incompatible flags at the same time as new functionality is added.
RELNOTES: Adds new-style JavaInfo provider constructor.
PiperOrigin-RevId: 194111925
|
|
|
|
| |
PiperOrigin-RevId: 194099006
|
|
|
|
|
|
|
|
|
| |
The CopyingSandboxedSpawn will be used by the upcoming Docker sandbox.
This is otherwise a no-op change.
RELNOTES: None.
PiperOrigin-RevId: 194096413
|
|
|
|
|
|
| |
TemplateVariableInfo.
PiperOrigin-RevId: 194088329
|
|
|
|
|
|
|
|
|
|
|
|
| |
be treated as a callable skylark object.
This will allow Skylark Provider objects to be better specified.
For example, "JavaInfo" can have a fully-documented, fully-specified @SkylarkCallable method with selfCall=true to represent the method JavaInfo(), instead of being a subclass of BaseFunction and requiring a @SkylarkSignature annotation.
There are no usages of this pattern introduced in this CL, and also no updates to docgen to support the new pattern. These will be introduced in another CL.
RELNOTES: None.
PiperOrigin-RevId: 194088227
|
|
|
|
|
|
| |
This should reduce memory consumption in NestedSet deserialization, which currently does not recycle Artifact instances.
PiperOrigin-RevId: 194083901
|
|
|
|
|
|
| |
RELNOTES[NEW]: TemplateVariableInfo can now be constructed from Skylark.
PiperOrigin-RevId: 194072452
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we report "Analyzing" when include scanning runs. But since we can
have shared C++ compile actions, only one of the group will be executed and only
one will be reported completed. Remaining shared actions currently stay with
"analyzing" forever.
This cl makes sure that these actions are properly handled when finished.
This is an encore of https://github.com/bazelbuild/bazel/commit/24f19ec2679dd93b1ac5b06e46f3b35807d6e217. In this incarnation I make sure that all actions that discover inputs are consistent in reporting their Analyzing status. Originally only CppCompileAction was doing that. Apparently we have more actions that discover inputs (e.g. LtoBackendAction) but these were not reporting Analyzing and therefore crashing on preconditions. This cl makes sure that all actions discovering inputs report their analyzing status.
RELNOTES: None
PiperOrigin-RevId: 194066513
|
|
|
|
|
|
|
| |
Removing stack trace unless verbose failures is on.
TESTED=unit test
PiperOrigin-RevId: 194060440
|
|
|
|
|
|
|
| |
Working towards #4571.
RELNOTES: CppRules: Feature configuration can be created from Skylark
PiperOrigin-RevId: 194048906
|
|
|
|
|
|
|
|
|
|
| |
for direct, transitive, and full compile-time jars; runtime jars; and instrumentation
metadata. These are trivial wrappers around the corresponding getters on the recursive
and non-recursive JavaCompilationArgs objects.
This is a no-op refactoring in preparation for flatting JavaCompilationArgs into JavaCompilationArgsProvider.
PiperOrigin-RevId: 194047064
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dynamic libraries
Term runtime input had 2 meanings in CppLinkAction:
1) input needed at runtime - dynamic library
2) input corresponding to the C++ runtime (libstdc++ or libc++)
This confused me and therefore the code :) This cl cleans this up to some extent by:
* renaming runtimeInput to runtimesInput, to at least give the reader a chance to catch the difference :)
* treating runtimesInputs as normal linker inputs, also downstream in CppLinkAction and LinkCommandLine
* Simplifying LibrariesToLinkCollector by removing explicit runtimesHandling.
RELNOTES: None
PiperOrigin-RevId: 194046439
|
|
|
|
|
|
|
| |
This allows a C++ file to include headers from a tree artifact, and pass header inclusion checks.
RELNOTES: None.
PiperOrigin-RevId: 193967617
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are effectively three different states a flag's value could be in:
1. Value is known to be non-default
2. Value is known to be default
3. Value is unknown (has been trimmed)
In addition to flagValues (which covers the first state), there are now
two additional sets covering the other two states. Neither of these sets
are used when manual trimming is disabled or when the entire set of flags
is known, in which case state 1 is represented by labels in the map,
state 2 is represented by labels not in the map, and state 3 doesn't exist.
This also adds the flag which controls whether manual trimming is active,
but it currently has no effect.
RELNOTES: None.
PiperOrigin-RevId: 193964624
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 193962460
|
|
|
|
|
|
|
|
|
| |
to check the direct dependencies for aar_import targets.
Currently the default value of this flag is not changed. And it will be enabled in a separate cl.
RELNOTES: None
PiperOrigin-RevId: 193959866
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
See: http://b/78455900
*** Original change description ***
Properly report completion of shared actions with input discovery
Currently we report "Analyzing" when include scanning runs. But since we can
have shared C++ compile actions, only one of the group will be executed and only
one will be reported completed. Remaining shared actions currently stay with
"analyzing" forever.
This cl makes sure that these actions are properly handled when finished.
RELNOTES: None
PiperOrigin-RevId: 193955856
|
|
|
|
| |
PiperOrigin-RevId: 193937177
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 193919970
|