| Commit message (Collapse) | Author | Age |
|
|
|
| |
PiperOrigin-RevId: 152169986
|
|
|
|
|
|
|
|
| |
a temporary Type.LabelVisitor instance per Attribute being visited. Instead, we can now create one temporary object per visitation. Getting rid of this dimension of scaling reduces the amount of garbage created.
RELNOTES: None
PiperOrigin-RevId: 152161836
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently ConfigSetting is treated specially; TransitiveTargetFunction
identifies it by name, then runs a special function on it. This change
makes ConfigSetting use a new options reference function in RuleClass,
which TransitiveTargetFunction will evaluate over the rule and use with
the options-to-fragments map to figure out which fragments are needed.
Although this is still a hack and not really a new feature on RuleClass,
this avoids a dependency on ConfigSettingRule from TransitiveTargetFunction,
which is necessary for ConfigSettingRule to be moved to rules/config.
RELNOTES: None.
PiperOrigin-RevId: 152156905
|
|
|
|
|
|
|
|
|
|
| |
Now that policy expands itself before being applied, clearValues never has to
clear more than a single value. This makes that more clear.
OptionValueDescription had not been consistently storing the snake_case name
for an option, leading to some weird behavior when removing the map of return
values from clearValues.
PiperOrigin-RevId: 152156746
|
|
|
|
|
|
|
|
|
|
|
|
| |
'create' method.
This paves the way for changing PathFragment to e.g. an abstract class with multiple subclasses. This way we can split out the windows-specific stuff into one of these concrete classes, making the code more readable and also saving memory (since the shallow heap size of the NonWindowsPathFragment subclass will hopefully be smaller than that of the current PathFragment).
This also lets us pursue gc churn optimizations. We can now do interning in PathFragment#create and can also get rid of unnecessary intermediate PathFragment allocations.
RELNOTES: None
PiperOrigin-RevId: 152145768
|
|
|
|
|
|
|
|
|
|
|
| |
Change the BuildEvent interface to accept a generic class of converters.
In this way, we won't have to change it again in the future, once more
converters are needed. In fact, a new converter is needed right now (will
be added in a follow-up patch) to allow build events to know the name of
named artifact groups already reported in the stream.
Change-Id: Ibb32ea5fff361e21bcf2d34818d8351a1da7a2e3
PiperOrigin-RevId: 152131870
|
|
|
|
|
|
|
|
|
| |
Closes https://github.com/bazelbuild/bazel/issues/1391.
RELNOTES: Removed --experimental_use_jack_for_dexing and libname.jack output of
android_library.
PiperOrigin-RevId: 152131075
|
|
|
|
|
|
|
|
|
|
|
|
| |
When building py_binary for host with --host_force_python=py3,
--python3_path is not taken, instead python3.exe is always used.
It doesn't work because python3.exe usually doesn't exist on
Windows. So here we set the default to python.exe
Fixed https://github.com/bazelbuild/bazel/issues/2752
Change-Id: Ie48156d93ae1f28338947ea121ab2071e1b820e1
PiperOrigin-RevId: 152130801
|
|
|
|
|
|
|
|
| |
allocating a garbage TranslatedPath object.
RELNOTES: None
PiperOrigin-RevId: 152130170
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks //src/test/shell/integration:force_delete_output_test
*** Original change description ***
Symlink output directories to the correct directory name
If the workspace directory is /path/to/my/proj and the name in the WORKSPACE
file is "floop", this will symlink the output directories to
output_base/execroot/floop instead of output_base/execroot/proj.
More prep for #1262, fixes #1681.
PiperOrigin-RevId: 152126545
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The RemoteSpawnRunner now implements the SpawnRunner interface.
Note that Google's internal implementations were also retrofitted, and
SpawnRunner is intended as a stable interface; that's also why I decided to
move all params into SpawnExecutionPolicy, which is, unfortunately, not quite
done yet.
The specification of SpawnRunner is also still incomplete. In particular, it
is still missing execution info keys, as well as inputs and outputs handling.
This is a step towards unifying all SpawnStrategy implementations, with the
SpawnRunner implementations performing the actual Spawn execution.
There should be no user-visible semantic changes to the code, but one small
fix:
- GrpcActionCache was trying to download files even if there were none
PiperOrigin-RevId: 152105696
|
|
|
|
|
|
|
| |
Now the actual workspace root might not be the basename of
the workspace, and everything should be removed anyway.
PiperOrigin-RevId: 152062690
|
|
|
|
|
|
|
|
|
| |
This is useful for IDEs and other tools utilizing command-line aspects
for reflection over build graph.
RELNOTES: None.
PiperOrigin-RevId: 152038248
|
|
|
|
|
|
| |
to avoid duplicating the logic.
PiperOrigin-RevId: 152035446
|
|
|
|
|
|
| |
https://github.com/google/error-prone/blob/master/docs/bugpattern/MutableConstantField.md
PiperOrigin-RevId: 152012020
|
|
|
|
| |
PiperOrigin-RevId: 152011915
|
|
|
|
|
|
|
|
|
| |
In this way, if several targets share output artifacts, those can be
reported in a more compact way.
Change-Id: I5a5bf30a533e05f55221431a1c500e606d411ef7
PiperOrigin-RevId: 151985307
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BuildConfiguration currently depends directly on the name of a rule class
to see if it is config_setting. This creates a circular dependency between
ConfigSetting and BuildConfiguration.
As ConfigSetting is being moved to rules/config, this circular dependency
will no longer work. This replaces the name special case for a special
property of the rule class, which only config_setting should set.
RELNOTES: None.
PiperOrigin-RevId: 151871084
|
|
|
|
|
|
|
|
|
|
|
|
| |
--incompatible_* flags
Note that if a developer adds a poorly-formatted incompatible change @Option, constructing an OptionsParser will now fail with an unchecked exception. This can cause some unit tests to fail in unexpected ways, but the developer should see an appropriate error message when the server starts up.
To be added: A separate integration test that ensures the expansions of --all_incompatible_changes don't clobber each other.
RELNOTES: None
PiperOrigin-RevId: 151858287
|
|
|
|
|
|
|
|
| |
for the new ToolchainProvider).
Change-Id: I3537e1ed924c598707759c4a7040d5ba00de559c
PiperOrigin-RevId: 151853764
|
|
|
|
|
|
|
|
|
|
| |
The exception is unchecked. The reasoning is that errors during parser construction should not occur, and when they do occur it is an internal error like a failed assertion.
This allows casual uses of the options parser to stay oblivious to the possibility of failures, consistent with how DuplicateOptionDeclarationException is currently [not] handled. At the same time, the dispatcher can catch the exception to fail gracefully (by printing to stdout instead of a log file) when parser construction fails for any reason.
RELNOTES: None
PiperOrigin-RevId: 151839620
|
|
|
|
|
|
|
|
| |
This includes the necessary changes to both CcSupport and JavaSupport to enable the protoc
flags when enabled on the Blaze command line as well as the plumbing to the C++ rules to allow
Kythe `.h.meta` files to be included as transitive required inputs.
PiperOrigin-RevId: 151833238
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ConfigSetting is being moved to rules/config, and that means that it
no longer has its special package-private access to BuildConfiguration.
The solution: a new TransitiveOptionDetails class which cuts down on
clutter in BuildConfiguration and is publicly accessible.
However, we don't really want anyone accessing BuildConfiguration's
TransitiveOptionsDetails - only config-related rules should ever need
it. As a result, BuildConfigurationOptionDetails provides public access
to BuildConfiguration's TransitiveOptionDetails, but is limited via
Blaze visibility to only configuration rules.
RELNOTES: None.
PiperOrigin-RevId: 151828068
|
|
|
|
|
|
|
| |
RELNOTES: Add --experimental_android_compress_java_resources flag to store java
resources as compressed inside the APK.
PiperOrigin-RevId: 151825809
|
|
|
|
| |
PiperOrigin-RevId: 151814714
|
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 151786403
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This rule has an implicit dependency on unified_launcher, which is hosted in an external repository at https://github.com/google/android-testing-support-library and must be set up in the WORKSPACE file with repository name @android_test_support. A future change will introduce an Android tools set-up macro that will create workspace rules for all of the remote Android tools, including unified_launcher.
Note that unified_launcher is not supported on Mac or Windows, so Bazel will only be able to successfully build the android_device rule on Linux.
Instructions to set up unified_launcher for use with android_device:
1. Install xvfb
2. In your WORKSPACE add
```
android_sdk_repository(name = "androidsdk") # Also set $ANDROID_HOME
git_repository(
name = "android_test_support",
remote = "https://github.com/google/android-testing-support-library",
commit = "79725fed7a6884074fb3647a683869e7141ecf64",
)
load(
"@android_test_support//tools/android/emulator:unified_launcher.bzl",
load_unified_launcher_deps = "load_workspace")
load_unified_launcher_deps()
```
In your BUILD file, you can create an android_device rule for a system image that you have installed in your Android SDK as:
```
android_device(
name = "my_device",
cache = 256,
default_properties = "@bazel_tools//tools/android/emulator:no_se_linux.properties",
horizontal_resolution = 640,
vertical_resolution = 800,
screen_density = 133,
ram = 2048,
vm_heap = 256,
system_image = "@androidsdk//:android-23_default_x86_files",
)
```
RELNOTES: Introduces experimental android_device rule for configuring and launching Android emulators.
PiperOrigin-RevId: 151766489
|
|
|
|
|
|
|
|
| |
outputFiles and outputFileMap objects in Rule.
RELNOTES: None.
PiperOrigin-RevId: 151764143
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--noexperimental_enable_critical_path_profiling flags are all specified, then Bazel will delete Actions from ActionLookupValues as they are executed in order to save memory.
Because an already-run action may output an artifact that is only requested later in the build, we need to maintain a way for the artifact to look up the action. But in most cases we don't need to keep the action itself, just its output metadata.
Some actions unfortunately are needed post-execution, and so we special-case them.
Also includes dependency change with description:
Move action out of key. This keeps action references from polluting the graph -- actions are just stored in one SkyValue, instead of being present in SkyKeys.
This does mean additional memory used: we have a separate ActionLookupData object per Action executed. That may reach ~24M for million-action builds.
PiperOrigin-RevId: 151756383
|
|
|
|
|
|
|
|
|
| |
This will improve android_binary build times and allow Bazel to remove a
dependency on our forked version of the deprecated ApkBuilderMain.
RELNOTES: None
PiperOrigin-RevId: 151749709
|
|
|
|
|
|
|
|
|
|
| |
information is useful, the critical path computer retains references to objects that could otherwise be cleared to save memory.
This change is probably not worth submitting on its own -- the benefit it provides is too slight. But my follow-up change unknown commit needs this option to be effective -- the critical path currently hangs on to references to every action in the graph, so we can't drop references to actions if it's enabled.
The critical path could probably be reworked in the future to not hang onto those references.
PiperOrigin-RevId: 151747605
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This rule allows users to define flags as part of the Bazel configuration.
These flags will be select-able through a new attribute on config_setting,
and settable through transitions within certain special rules.
This rule is currently not supported by any other rules, not even
config_setting, and its values cannot be set; accordingly, it's not very
useful yet.
RELNOTES: None.
PiperOrigin-RevId: 151746523
|
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 151746179
|
|
|
|
|
|
|
|
| |
in Skylark.
RELNOTES: None.
PiperOrigin-RevId: 151744710
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks inclusion of C++ system headers.
*** Original change description ***
Extract --sysroot flag from blaze and move it into crosstool
RELNOTES: None.
PiperOrigin-RevId: 151742077
|
|
|
|
|
|
|
|
|
|
|
|
| |
That means the prefetching execution is more similar to the real execution,
it will fetch more globs and throw less exceptions.
In the code path, one exception was thrown for almost each statement. With
this change, many BUILD files can be evaluated without an exception.
RELNOTES: None.
PiperOrigin-RevId: 151740684
|
|
|
|
|
|
|
|
| |
new_foo_repository rules.
Change-Id: Iadcc24bb2a207126cec9aa31faba6d76ee80da41
PiperOrigin-RevId: 151739968
|
|
|
|
|
|
|
| |
This isn't used anymore, it's the same as STRING_DICT, deleting so no one tries
to use it.
PiperOrigin-RevId: 151738915
|
|
|
|
|
|
|
|
|
| |
Prevent OptionsBases with conflicting names due to --no boolean flag aliases to
successfully combine into parser.
Also remove the comment about --no_ not being documented, since it has been documented since Bazel was open-sourced.
PiperOrigin-RevId: 151738453
|
|
|
|
|
|
|
|
|
| |
Once the ResourceFilter object is in AndroidConfiguration, we can start
tweaking it using dynamic configuration (next review).
RELNOTES: none
PiperOrigin-RevId: 151737284
|
|
|
|
|
|
|
|
| |
This change is one step towards removing --nouse_singlejar_apkbuilder.
RELNOTES: None
PiperOrigin-RevId: 151730390
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note 1) Explanation of the flags:
--explicit_java_test_deps: This is a flag independent of the others, and forces users to specify the JUnit deps. We should try to make this flag default to true in a future release, irrespective of the work around persistent java tests.
--experimental_testrunner: Bazel-only flag affecting switching from the BazelTestRunner to the ExperimentalTestRunner which will run the tests in a separate classloader. --explicit_java_test_deps is desired for this to ensure once we split the classpaths of the TestRunner and the TestTarget, the TestTarget does not hit a ClassNotFoundException, due to missing JUnit deps.
--test_strategy=experimental_worker: This is the existing flag, which in turn depends on --experimental_testrunner flag, since only the ExperimentalTestRunner is capable to running java tests persistently.
Note 2) There was no clean way to check for the flags defined in JavaOptions within TestActionBuilder (as I was checking the "tag=experimental_testrunner" before), without making TeasActionBuilder's build rules depend on java rules (yikes!). Hence, I created a new method compatibleWithStrategy() within each fragment, so I could check if WorkerTestStrategy could be compatible with the user specified flags. Thanks to Greg for suggesting this approach!
RELNOTES: None
PiperOrigin-RevId: 151729869
|
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 151729291
|
|
|
|
|
|
|
|
|
| |
Record the starting times of test actions, so that they can be reported
in the build event protocol.
Change-Id: I28e8d7d6ad39d91f4ffdd8a6161a5fc30f9a39b8
PiperOrigin-RevId: 151724760
|
|
|
|
|
|
|
| |
This should be morally equivalent to prefixing, with the benefit that we won't
prematurely expand NestedSets (not cheap) to get the length.
PiperOrigin-RevId: 151721361
|
|
|
|
|
|
|
|
|
|
| |
as argument.
This is needed because which proguard map that gets added as an argument to mainDexListAction depends on whether or not Rex is enabled
RELNOTES: None
PiperOrigin-RevId: 151720305
|
|
|
|
|
|
|
|
| |
For SetValue and UseDefault policies on expansion flags or flags with implicitRequirements, expand the policy into policy for each of its sub-flags. For SetValue, this addresses the issue with policies on expansion flags with overridable=true not actually letting user flags overrride the expansion. For UseDefault, this formalizes the behavior where UseDefault will wipe all user-provided flags that expand from a banned expansion flag, and will allow later work to guarantee that a later policy can override the expansion policy's subflags.
Since expansion flags do not have value, break if the invocation policy uses AllowValue or DisallowValue on an expansion flag.
PiperOrigin-RevId: 151718539
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The RuleContext object is not available when creating dynamic configuration
transitions. Removing it from ResourceFilter's state allows us to work with
ResourceFilter objects while creating those transitions. If we didn't do this,
we'd need to seperate the rest of ResourceFilter's state into a seperate class
so that we could work with it as part of doing dynamic configurations.
In the next reviews, I'll start actually creating dynamic configurations based
on ResourceFilter state.
Also, create a withAttrsFrom method that can be used in dynamic configuration
transitions, and generally migrate methods that work with attributes from
RuleContext to AttributeMap when practical.
To support these changes:
No longer keep the parsed lists of FolderConfiguration and Density objects as
fields of the ResourceFilter, instead, write functions that get them when
needed. We want to have access to a RuleContext when we initialize them to avoid
errors, and we don't have one in the withAttrsFrom method which will be called
as part of transitioning with dynamic configurations.
We no longer have those parsed lists to represent whether the object filters
during execution or analysis, so replace them with a seperate enum field for
filter behavior. Include a FILTER_IN_ANALYSIS_WITH_DYNAMIC_CONFIGURATION
option, even though it won't fully be used until the dynamic configuration
transition is taken advantage of in the next few reviews.
RELNOTES: none
PiperOrigin-RevId: 151715400
|
|
|
|
|
|
|
|
|
|
| |
If the workspace directory is /path/to/my/proj and the name in the WORKSPACE
file is "floop", this will symlink the output directories to
output_base/execroot/floop instead of output_base/execroot/proj.
More prep for #1262, fixes #1681.
PiperOrigin-RevId: 151712384
|
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 151688820
|