| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
RELNOTES[INC]: Using tabulation for identation is now fobidden in .bzl files
PiperOrigin-RevId: 160888064
|
|
|
|
|
|
|
|
|
|
| |
Fixes #3295.
Users requested this [1] and it is useful for example to pass it as a value to java_common.compile#strict_deps.
[1] https://stackoverflow.com/questions/44827704/bazel-can-a-skylark-action-read-a-command-line-flag-strict-java-deps
PiperOrigin-RevId: 160886151
|
|
|
|
|
|
| |
Make sure that we print the failing command / target in all cases.
PiperOrigin-RevId: 160881591
|
|
|
|
|
|
|
|
|
|
| |
I'm planning to switch the remote worker over to the on-disk storage system,
and delete the in-memory option. Currently, running a Bazel build with the
in-memory storage system uses up over 50% of the total available memory on my
machine (I only have 32 GB total), and grinds it to a complete halt (unless I
close most of my apps) on a simple build of //src:bazel.
PiperOrigin-RevId: 160877546
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The script more logically belongs in
src/main/native/windows than in src/main/native.
Also move the //src/main/native:windows_jni rule
into //src/main/native/windows:windows_jni, so the
logic of building the JNI library is fully
contained in that package.
Change-Id: I96e19003932cc0ddc5af3471b0b31a1aec09b8fa
PiperOrigin-RevId: 160876594
|
|
|
|
|
|
|
|
|
|
| |
When showing the summary of test results on the terminal, for multi-configuration
builds it can happen that the same label occurs twice (as the test was run for
multiple configurations). In this case, also show the configuration (as mnemonics)
for all tests in the summary.
RELNOTES: None
PiperOrigin-RevId: 160875427
|
|
|
|
|
|
|
|
|
|
| |
In some cases, when the configuration is known anyway, it might help debug
why an action failed. For the time being, we only report of id of the
configuration without guaranteeing that details about the configuration are
shown in the sream.
Change-Id: I23bcad2f6407e03c7defcdd795629dfca2b1ea92
PiperOrigin-RevId: 160874546
|
|
|
|
| |
PiperOrigin-RevId: 160872755
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Up until now we allowed implicit iteration, e.g.:
flag_group { flag: '%{some_sequence_variable}' }
From now on, snippet above will raise an error. We require explicit
'iterate_over' message, e.g.:
flag_group {
iterate_over: 'some_sequence_variable'
flag: '%{some_sequence_variable}'
}
RELNOTES: Implicit iteration in the CROSSTOOL has been removed, use explicit 'iterate_over' message.
PiperOrigin-RevId: 160871888
|
|
|
|
|
|
|
|
|
|
| |
Also extend the API to throw exceptions rather than having to wrap or swallow.
This is in preparation for adding yet another implementation using an on-disk
cache. Having the RemoteWorker keep everything in memory is not good for my
sanity.
PiperOrigin-RevId: 160871586
|
|
|
|
|
|
|
|
| |
Instead, let's reuse the cross-platform {Get,Set,Unset}Env() functions
when possible.
Change-Id: I40b4ff09c66fe238d5b3d70e49f91705cea64b0c
PiperOrigin-RevId: 160870850
|
|
|
|
|
|
|
| |
RELNOTES:
Evaluation will soon use checked arithmetics and throw an error instead of
overflow/underflow.
PiperOrigin-RevId: 160834366
|
|
|
|
|
|
|
|
|
| |
To keep the build-event JSON file more compact, do not generate
unnecessary white space. This also simplifies navigation through the
file as now we have precisely one JSON object per line.
Change-Id: I385f3f86d32f70c935e406a22234745f1d6e6515
PiperOrigin-RevId: 160832955
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 160831413
|
|
|
|
|
|
| |
Replacing checkNotNulls (which throws NPE) with throwing EvalExceptions in java_common, in order for blaze to output a nice error message instead of crashing.
PiperOrigin-RevId: 160830397
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 160828805
|
|
|
|
|
|
|
|
|
|
| |
If an aspect completed unsuccessfully, there are no artifacts created.
Internally, this is represented by the ArtifactsToBuild object being
a null pointer. When asked for the built artifacts correctly handle
that case and return an empty Collection.
Change-Id: Ie0b0486354bb217834254518f35c97b7c9529481
PiperOrigin-RevId: 160827964
|
|
|
|
|
|
|
|
| |
It also changes the return value of ctx.template_action to None, so a
very minor breaking change. There are no internal usages at least.
RELNOTES: None.
PiperOrigin-RevId: 160825636
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 160817326
|
|
|
|
|
|
|
|
|
|
|
|
| |
Docs currently shows this:
> C and C++ source files: `.c`, `.cc`, `.cpp`, `.cxx`, `.c++.C`
I was wondering who the heck uses `.c++.C`.
Closes #3282.
PiperOrigin-RevId: 160810749
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Linux/MacOS, sh_binary creates an output file
with the same name as the rule. The file is a
symlink pointing to the main script of the rule
(sh_binary.srcs only allows one file.)
On Windows sh_binary also creates an output file
called the same as the rule, but it's a copy of
the main script file (due to lack of symlink
support on Windows). However the rule now also
creates the <rulename>.cmd output, which is a
wrapper script similar to the
java_binary-generated launcher.
If however the sh_binary rule's name ends with
".exe", ".cmd", or ".bat", and its main file also
ends with the same extension, then sh_binary will
not create the launcher .cmd file, and will copy
the main file to the output tree instead.
Change-Id: Idcf92ce3bb254bd6d9a1fb5c659a52220efe19aa
PiperOrigin-RevId: 160805720
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 160695158
|
|
|
|
|
|
| |
detection.
PiperOrigin-RevId: 160686932
|
|
|
|
|
|
|
|
|
|
| |
To limit rollout of this potentially risky feature, a new policy
is added to the --feature_control_policy feature list. The contents
of the package_group pointed to by that label are then used to control
which targets are allowed to use feature flags and related features.
RELNOTES: None.
PiperOrigin-RevId: 160686186
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 160684786
|
|
|
|
|
|
|
|
| |
to change some other exception types into IOExceptions.
TESTED=unit tests
RELNOTES: n/a
PiperOrigin-RevId: 160677771
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 160675033
|
|
|
|
|
|
|
| |
This optimization reduces the size of Android apps that use Proguard by ~0.2 - 0.3% depending on the minSdkVersion.
RELNOTES: None.
PiperOrigin-RevId: 160673030
|
|
|
|
|
|
|
| |
PathFragment.TO_PATH_FRAGMENT
RELNOTES: None.
PiperOrigin-RevId: 160668541
|
|
|
|
|
|
|
| |
Fixes https://github.com/bazelbuild/bazel/issues/3045.
RELNOTES: Enable --incremental_dexing for Android builds by default. Note that some dexopts are incompatible with incremental dexing, including --force-jumbo.
PiperOrigin-RevId: 160650101
|
|
|
|
|
|
| |
Progress on #2614.
PiperOrigin-RevId: 160649080
|
|
|
|
|
|
|
|
|
|
| |
This is a step forward to having the same semantics for java_library and
custom Skylark rules that use java_common.compile, facilitating the migration
from native Java rules to Skylark.
Progress on #2614
PiperOrigin-RevId: 160644961
|
|
|
|
|
|
|
|
|
|
|
| |
Also implement deprecated ctx.action(...) by delegating to these new
functions.
Test migration will happen in the follow-up Cl.
In this CL, ctx.actions.run_shell() still accepts 'arguments' parameter,
removal of that is a follow-up too.
RELNOTES: None.
PiperOrigin-RevId: 160643870
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the Java JNI sources to a separate package:
c.g.devtools.build.lib.windows.jni and
c.g.devtools.build.lib.windows.runfiles.
Make the native method declarations private,
create public wrapper methods for them that ensure
that the JNI library is loaded.
Split the C++ JNI source processes.cc into two
parts (processes-jni.cc and file-jni.cc), extract
common functionality to jni-util.{h,cc}.
This change preparse the code for Android rule
support on Windows, specifically it lets the
Android BusyBox use the file JNI library so it can
create junctions on Windows to work around long
path issues when calling external tools.
See https://github.com/bazelbuild/bazel/issues/3264
Change-Id: I7f1a746d73f822ae419d11b893a91f4eb45d64da
PiperOrigin-RevId: 160643355
|
|
|
|
|
|
|
|
|
|
| |
All options need to explicitly list their category and effect. If they are uncategorized, this makes the lack of information obvious. Remove defaults from the annotation to enforce this.
Also enforce the sanity check that no option should have UNKNOWN or NO_OP effects listed with other effect tags.
Includes some last default sets for options I missed in the previous mass-setting change, and some that were added since.
PiperOrigin-RevId: 160641861
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dynamically Configured Resource Filtering change 1/6
To enable dynamically configured resource filtering, we'll need to be able to
pass filtered resources into resource processing code used by android_library
targets. The resource parsing action, used only in android_library targets,
takes the LocalResourceContainer as an input, unlike android_binary processing
code which never used it directly.
Abstract the code for actually building the collection of resource roots out of the withResources method, and create an additional method for calling it from resource filtering.
Also, split some common test code out of ResourceFilterTestBase to make a ResourceTestBase class for testing changes to this (and eventually, other) resource-oriented classes, and create LocalResourceContainerTest for this class in particular.
RELNOTES: none
PiperOrigin-RevId: 160640192
|
|
|
|
|
|
|
| |
It's now easier to customize Printer if in different situations objects should
be printed differently. Also its API is cleaner now. Names of methods of SkylarkValue objects now reflect names of Skylark functions: SkylarkValue#repr and SkylarkPrintableValue#str.
PiperOrigin-RevId: 160635154
|
|
|
|
|
|
|
|
|
|
|
|
| |
This cl promotes //tools/osx/crosstool to be fully specified on its own, without
any blaze patches needed. While at it, I (think I) unified objc and c++ coverage
features. Other than coverage, this cl only adds features that bazel would add
otherwise.
Ping #2420
RELNOTES: ObjC and C++ coverage feature is unified under name 'coverage'
PiperOrigin-RevId: 160633192
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 160630261
|
|
|
|
|
|
|
| |
Fixes fallout from https://github.com/bazelbuild/bazel/commit/fda985b069ed4cc1966a6ced5743c396f91ac688.
RELNOTES: none
PiperOrigin-RevId: 160626838
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 160621674
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 160619371
|
|
|
|
|
|
|
|
| |
retry strategy may need tuning.
Other behavior changes: swallowing gRPC CANCELLED errors when the thread is interrupted, as these are expected and just make debugging difficult. Also, distinguishing between the gRPC DEADLINE_EXCEEDED caused by the actual command timing out on the server vs. other causes (the former should not be retriable, while the latter should retry).
TESTED=unit tests, remote worker on Bazel
PiperOrigin-RevId: 160605830
|
|
|
|
|
|
|
| |
Chunker.Builder in my next change, so all the from factory methods are removed.
TESTED=unit test
PiperOrigin-RevId: 160594730
|
|
|
|
|
|
|
| |
With a few manual fixes for readability.
RELNOTES: None.
PiperOrigin-RevId: 160582556
|
|
|
|
|
|
|
|
|
| |
--experimental_use_absolute_paths_for_actions.
These flags are old and unused -- with the deletion of xcodegen, addition of Tulsi, and near-migration to crosstool objc compilation, these flags are long-deprecated and are now cleaned up.
RELNOTES: None.
PiperOrigin-RevId: 160578161
|
|
|
|
|
|
| |
Automated formatting fixes standardize the @Option annotation.
PiperOrigin-RevId: 160567787
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 160566592
|
|
|
|
|
|
| |
The previous implementation stores a copy of the param file's path fragment with an '@' prepended. This can add up if you have a lot of params files, but can be avoided by deferring that string expansion.
PiperOrigin-RevId: 160559793
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 160553181
|