| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This gives the ability to select on config_feature_flags. They still
have not been publicly documented, because there's no way to set them.
But, progress.
config_setting still needs to have either values or flag_values; it cannot
have both be empty. However, values is no longer mandatory, nor must it be
nonempty (as long as flag_values is set nonempty).
RELNOTES: None.
PiperOrigin-RevId: 152515036
|
|
|
|
|
|
|
| |
Previously it returned a frozen list. Using frozen mutables as part of the API specification is an unnecessary complication and should be avoided.
RELNOTES[INC]: The return type of depset.to_list() is now a list rather than a frozen list. (Modifying the list has no effect on the depset.)
PiperOrigin-RevId: 152504943
|
|
|
|
|
|
|
|
|
|
| |
In the experimental UI, increase the rate limit for updates to the progress
bar over time, if it cannot be updated in place. In this way, we can get snappy
first progress descriptions, while not overwhelming the user with too many progress
messages.
Change-Id: I769f1a9ef4304b613d40ece42b87df22881549cd
PiperOrigin-RevId: 152502295
|
|
|
|
|
|
|
| |
All android_sdk rules are required to have the apksigner binary, which was not included in the build tools until version 24.0.3. So this check is no longer necessary. Instead, we check in AndroidSdkRepositoryFunction.
RELNOTES: None
PiperOrigin-RevId: 152498753
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change, suggested by @tylerfox at
https://github.com/tensorflow/tensorflow/issues/851#issuecomment-230810921
allows Bazel 0.4.5 to be built on a Jetson TX1 with JetPack 3.0.
The other of @tylerfox's suggested changes was made in 7c4afb6.
Refs #1264
Closes #2703.
PiperOrigin-RevId: 152498304
|
|
|
|
|
|
|
|
|
|
| |
Extend the functionality of the BuildEventStreamer to report those parts
of NestedSets of Artifacts not reported earlier. In this way, duplicate
reporting can be avoided, without the events themselves having to know
which artifacts are known already.
Change-Id: Ia959c28c440301860eac57ea5d9a712c0d49ebdf
PiperOrigin-RevId: 152497672
|
|
|
|
| |
PiperOrigin-RevId: 152497640
|
|
|
|
|
| |
This is ported from StandaloneSpawnStrategy.
PiperOrigin-RevId: 152493898
|
|
|
|
|
|
|
|
|
| |
macOS version strings that have only two components, e.g. "10.12", were
always failing the check that the macOS version is >= 10.11, causing
Bazel to erroneously think sandboxing isn't supported
Change-Id: Ifa4a01fc304e7620502d3f0f9f70c3b500d23864
PiperOrigin-RevId: 152493682
|
|
|
|
| |
PiperOrigin-RevId: 152491822
|
|
|
|
|
|
|
|
| |
Usually, Bazel creates the sandbox directories underneath its
output_base. With --experimental_sandbox_base you can specify a
different parent directory for this, e.g. /dev/shm to run all sandboxed
actions on a memory-backed filesystem.
PiperOrigin-RevId: 152490815
|
|
|
|
|
|
|
|
|
| |
The LocalSpawnRunner is a non-sandboxed local execution implementation, which
will replace the current StandaloneSpawnStrategy. The code has been around for
a long time and has seen a lot of bugfixes. It also supports local prefetching,
which is required for Google. I have a follow-up change to make it support
Windows, so it's not a drop-in replacement for StandaloneSpawnStrategy yet.
PiperOrigin-RevId: 152486973
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes https://github.com/bazelbuild/bazel/issues/2660. Basically,
if we elect to keep the journal during PersistentMap.save(), we
shouldn't stomp over it the next time save() is called.
In writeJournal(), we now check if the journal file exists, and open
it in append mode if it does. Alternatively, we could simply not close
(and thus forget about) the journal in save(), but that would leak the
journal file handle if save() was never called with keepJournal()
returning false.
Change-Id: Id00732f161c8b5a082a6c109aee115591ace2ea7
PiperOrigin-RevId: 152480978
|
|
|
|
|
| |
--no_ prefixes for boolean flags are deprecated. Error out nicely if --no_ is supplied.
PiperOrigin-RevId: 152434290
|
|
|
|
|
|
|
|
|
| |
The user interface is not changing. The policy will still be accepted as a flag passed to the client, as a startup flag (before the command), it will just no longer trigger server restarts and will not be passed on to a bazel server as part of the startup arguments. In batch mode, however, it will still be a startup argument, because the RunRequest proto is not sent, and all invocations restart bazel in batch mode anyway.
Since invocation policy only affects command arguments, and changes in command arguments do not cause server restarts, this is consistent with other server restart behavior.
RELNOTES: Changing --invocation_policy will no longer force a server restart.
PiperOrigin-RevId: 152426207
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 152416858
|
|
|
|
|
| |
Change-Id: Ied06efd4bc68f604975b1e8e3fc70817a577d563
PiperOrigin-RevId: 152412538
|
|
|
|
| |
PiperOrigin-RevId: 152412325
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Better specify the BuildEventTransport interface. Besides clarifying threading
and blocking issues, this change also clarifies error handling/reporting.
After several discussions we concluded that the BuildEventTransport interface
should not provide error reporting / handling facilities, as there is not much
bazel could do with this information. Instead, a transport may decide for
itself if an error is fatal and abort the build or if an error should be logged
to the user's terminal or if it should be ignored.
Furthermore, changing the close() method lays the groundwork for an upcoming
change that will report the transport shutdown status to the user command
line.
PiperOrigin-RevId: 152408938
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 152400979
|
|
|
|
|
| |
.collectCompileTimeDependencyArtifacts instead of retrieving the JavaCompilationArgsProviders twice and checking for duplicates.
PiperOrigin-RevId: 152398536
|
|
|
|
|
|
|
|
|
| |
If told to not use curses, also do no show the progress in the terminal title,
even if told to do so. If curses are not available, most likely OSC controll
sequences are not available either.
Change-Id: I0e14e36aaa32dfeffb52ed701e31b83085d63e68
PiperOrigin-RevId: 152393651
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This relies on the explicit state transition in MetadataHandler to decide
whether the chmod call is necessary (we must never call chmod if the action
was not executed).
This is a prerequisite for #1525. If we want to use ctime for detecting file
content changes (which is more reliable than just mtime), then we must call
chmod before stat, since chmod affects ctime.
Before this change, we were caching the stat in ActionMetadataHandler, but
calling chmod after action execution in SkyframeActionExecutor, which is the
wrong order of calls. However, we must be able to stat in ActionMetadataHandler
for cases where a single action runs multiple Spawns where one spawn's output
is a subsequent spawn's input.
Remove MetadataHandler.isInjected, which is no longer used anywhere.
PiperOrigin-RevId: 152387133
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 152386957
|
|
|
|
|
|
|
|
|
|
|
|
| |
added tests. This should not conflict with any of Ulf's upcoming CLs. I need it
in preparation for the next CL, which fixes the bug that I don't limit the
message size according to grpcChunkSizeBytes and don't do chunking in
RemoteWorker.java, causing it to fail on uploading large outputs.
TESTED=unit / integration tests
RELNOTES: n/a
PiperOrigin-RevId: 152385956
|
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 152369293
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ActionMetadataHandler does an explicit state transition on
discardOutputMetadata. Before the call, it may be used for action cache
checking, and after the call it may be updated with execution results.
Several of the methods now throw if they're used incorrectly, so I had to
refactor the control flow in ActionExecutionFunction to correctly call
discardOutputMetadata on the MetadataHandler in all cases. I discovered a
resource leak (of FileOutErr) in IncludeParseFunction while I was at it, so
I plugged that as well.
One step towards #1525.
PiperOrigin-RevId: 152363982
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When serializing a large number of related nested sets needs to be serialized
in an efficient way, it is necessary to access the internal structure of a nested
set to efficiently deduplicate shared content. Add a new class that provides such
a view on a nested set.
Note: part of this change (in particular, the addition of the NestedSetView class)
was accidentally committed as part of 617bb896dc5d2b815449459e991c577237d7a7fc.
Change-Id: I03660a228a66bbd6d3df2d3e78e8349be2d55f41
PiperOrigin-RevId: 152362816
|
|
|
|
| |
PiperOrigin-RevId: 152356545
|
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 152340847
|
|
|
|
|
|
|
|
| |
keep references to actions indefinitely. Instead, once an action is finished executing, keep just some metadata about it. This allows actions to be unconditionally dropped when running with --batch, --discard_analysis_cache, and --keep_going, even if profiling is enabled.
The additional fields here add between 8 and 12 bytes per component, and we have one component per action. This additional penalty is only incurred when we are already saving memory, so I think it's ok. The full penalty will be realized only towards the end of the build, when every action has started executing at least once. Users can still specify --noexperimental_enable_critical_path_profiling if they want to squeeze even more memory out.
PiperOrigin-RevId: 152328870
|
|
|
|
| |
PiperOrigin-RevId: 152307322
|
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 152291766
|
|
|
|
|
|
|
|
|
|
|
| |
This change makes Bazel work with data binding runtime libraries 1.3.1
and buildtime libraries 2.3.1.
The biggest change is to configure the annotation processor with javac
annotation processor flags ("-Aflag=value") instead of directly through
annotations in a template Java file.
PiperOrigin-RevId: 152282448
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ConfigSetting was previously in analysis/config, where it was slightly out
of place (as it is a rule, not an integral part of the analysis backend).
This is also necessary to integrate it with ConfigFeatureFlag, as otherwise
this would be a circular dependency (analysis/config <-> rules/config).
ConfigFeatureFlagRule itself has been moved into ConfigRuleClasses, where
it can use the ConfigBaseRule and the nonconfigurable reason from the other
configuration rules.
RELNOTES: None.
PiperOrigin-RevId: 152275823
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Broke mac_jdk7_test.
*** Original change description ***
Refactoring the chunking logic out of GrpcActionCache, and cleaning it up. Also
added tests. This should not conflict with any of Ulf's upcoming CLs. I need it
in preparation for the next CL, which fixes the bug that I don't limit the
message size according to grpcChunkSizeBytes and don't do chunking in
RemoteWorker.java, causing it to fail on uploading large outputs.
TESTED=unit / integration tests
RELNOTES: n/a
PiperOrigin-RevId: 152270056
|
|
|
|
| |
PiperOrigin-RevId: 152264528
|
|
|
|
|
|
| |
e.g.: cmd = "$(JAVA) foo.java ..."
PiperOrigin-RevId: 152263822
|
|
|
|
|
|
| |
This is only useful for debugging invocation policy itself, not as much for understanding its effect on a user command line, so this log statement will only occur at log levels fine and higher.
PiperOrigin-RevId: 152259362
|
|
|
|
|
|
|
|
|
|
|
|
| |
added tests. This should not conflict with any of Ulf's upcoming CLs. I need it
in preparation for the next CL, which fixes the bug that I don't limit the
message size according to grpcChunkSizeBytes and don't do chunking in
RemoteWorker.java, causing it to fail on uploading large outputs.
TESTED=unit / integration tests
RELNOTES: n/a
PiperOrigin-RevId: 152258232
|
|
|
|
|
| |
Change-Id: I7615d3e6e33e0c48f18b2506a135f45ce3705a38
PiperOrigin-RevId: 152256914
|
|
|
|
|
|
| |
--experimental_objc_crosstool=all
PiperOrigin-RevId: 152254287
|
|
|
|
|
|
|
|
| |
(Pull NestedSet creation outside of a loop)
RELNOTES: None.
PiperOrigin-RevId: 152253535
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The intention is for the SpawnRunner interface to be the single, unified
interface for running Spawns, so it needs to cover both execution and error
reporting functionality for all current implementations, some of which are
internal to Google.
Note in particular the unified status code - it reports success if the
subprocess was executed regardless of its exit code, which is reported
separately.
PiperOrigin-RevId: 152252975
|
|
|
|
|
|
|
| |
to CROSSTOOL
Change-Id: Ic6ee5a22412281743267a40623f4a8514a2e70f6
PiperOrigin-RevId: 152252048
|
|
|
|
|
|
|
|
| |
(*) instead of using duplicate method names.
(*) Technically it's not a proper method signature since it contains parameter names instead of parameter types.
PiperOrigin-RevId: 152251143
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new class wraps an existing SpawnRunner and adds remote caching. Ideally,
the wrapped runner should be local and sandboxed, but this is not currently
enforced. The new class is not hooked up to anything yet.
The added test indicates that the RemoteActionCache interface is still more
complex than necessary - in particular, we should merge downloadAllResults and
downloadBlobs (for stdout/stderr) into a single method, and also change the
upload to a single combined method in a similar way instead of two calls. Doing
so allows the RemoteActionCache implementation more leeway in how it wants to
implement these, potentially improving parallelism and performance.
One step towards #1413.
PiperOrigin-RevId: 152245644
|
|
|
|
|
|
| |
Fixes #1892.
PiperOrigin-RevId: 152245566
|
|
|
|
|
|
|
| |
This is in preparation for recording ctime as well as mtime, in order to
make progress towards #1525.
PiperOrigin-RevId: 152243422
|