| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
RELNOTES:
When the lvalue of an augmented assignment is a list, we now throw an error
before evaluating the code (e.g. `a, b += 2, 3`).
PiperOrigin-RevId: 165906611
|
|
|
|
|
|
|
| |
RuleContext.shouldCreateRunfilesSymlinks() itself.
RELNOTES: None.
PiperOrigin-RevId: 165774395
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
passing the --post_build_query flag to a build command, with a query expression as the argument. Bazel then executes this query on the configured target graph as constructed by the build command.
Since the prepare graph -> query workflow is how SkyQueryEnvironment works, this is mostly just copying that.
Main missing features/code cleanups:
* Recursive target patterns (/...) are not supported.
* There is no way to specify the configuration of the targets in your query.
* Configuration output is totally opaque (just the hash, or null if no configuration).
* More generally, no output options.
* Some features (visibility, label attrs) not supported.
* No edge filtering (host deps, implicit deps).
* Aspects are totally ignored.
* Graceful failure on errors, edge cases, incompatible flags (like the TAP flags that discard edges).
* Code hygiene issues (calling test-only method to get to Skyframe graph, some code duplication across ConfiguredTargetQueryEnvironment and SkyQueryEnvironment).
Most of the features I plan to leave to rules-side people, since I think they won't be too hard for a general Blaze developer to implement, and designing the right features and user interfaces for these things is better left to the rules side.
PiperOrigin-RevId: 165747829
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This accomplishes a few goals:
1. Removes the outdated BuildConfiguration.StaticConfigurationApplier code.
2. Removes the TransitionApplier abstraction completely. This was an awkward
bridge meant to support both static and dynamic implementations.
3. Moves transition logic to its own dedicated class: ConfigurationResolver.
This no longer belongs in BuildConfiguration, which we ultimately want to
become a simple <key, value> map.
Part of the static config cleanup effort.
PiperOrigin-RevId: 165736955
|
|
|
|
| |
PiperOrigin-RevId: 165731260
|
|
|
|
| |
PiperOrigin-RevId: 165730337
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now Bazel build a Windows exe to launch the python self-extracting zip
file by default, using --windows_exe_launcher=0 to switch back to cmd
wrapper.
The extra zip file with shebang preprended is not built on Windows
anymore, even when using cmd wrapper.
Change-Id: Ic7060326f19ca6e2e73ea8d8211afd1c7618083c
PiperOrigin-RevId: 165707076
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 165705342
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
android_libraries can now be used in the resources attribute. However, if these
libraries contain non-resource information, it won't get picked up. To prevent
unexpected behavior, fail if such libraries are used as resources.
Adding a temporary boolean to AndroidResourcesProvider seems to be the most
straightforward way of doing this. The alternative, having the consuming target
check all relevant providers for non-resource information, would be much
messier.
RELNOTES: None
PiperOrigin-RevId: 165703578
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Extract some funtions into NativeLauncherUtil.java
So that they can also be used by Python and Java launcher.
2. Derive runfiles directory from mainExectuable
yielding "%{name}.cmd.runfiles" or "%{name}.exe.runfiles"
3. Removed bash_main_file key, we can assume the main file is next the
launcher just without .exe suffix.
By doing this, we don't have to worry about passing RunfilesPath or
ExecPath. RunfilesPath has ../ prefix for external file, ExecPath
contians ./bazel-out/... for generated file. If main file is a
generated file from external repository, neither of them are correct.
Change-Id: Ie0c35f6030f6229c28d935d8fb3cb6a8af5af29c
PiperOrigin-RevId: 165699975
|
|
|
|
|
|
|
| |
defines it
RELNOTES: None.
PiperOrigin-RevId: 165695975
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 165685048
|
|
|
|
|
|
|
|
| |
This is always true.
Part of the static config cleanup effort.
PiperOrigin-RevId: 165628823
|
|
|
|
| |
PiperOrigin-RevId: 165622047
|
|
|
|
|
|
|
|
|
| |
This makes these flags accessible to all commands, including some that don't do anything with Skylark (e.g. canonicalize-flags). This leads to spammier help messages. But the benefit is that it allows them to appear on a "common" line in the .bazelrc.
Fixes #3538.
RELNOTES: Skylark-related options may now appear as "common" command options in the .bazelrc
PiperOrigin-RevId: 165620829
|
|
|
|
|
|
|
| |
The options parser already has a static cache of all the reflection work performed. There can still be costs associated with the obtaining and combining of options classes (see the BlazeCommandDispatcher's additional caching), but in this case, each parser is made with a single options class, and none of the class-name extraction was being cached, so I think there was nothing gained.
RELNOTES: None.
PiperOrigin-RevId: 165613107
|
|
|
|
|
|
|
|
| |
BuildConfigurationCollection.Transitions.
Part of the static config cleanup effort.
PiperOrigin-RevId: 165607492
|
|
|
|
|
|
|
|
|
| |
Also, promote --experimental_desugar_for_android to --desugar_for_android.
Fixes https://github.com/bazelbuild/bazel/issues/2871
RELNOTES: All Android builds now use the desugar tool to support some Java 8 features by default. To disable, use the --nodesugar_for_android flag.
PiperOrigin-RevId: 165606988
|
|
|
|
|
|
|
|
|
|
| |
I added support for exposing the GNU linker (ld) for genrule() and Skylark.
For reference: https://stackoverflow.com/questions/45560314/building-kernel-module-with-bazel
Closes #3557.
PiperOrigin-RevId: 165600633
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 165600058
|
|
|
|
| |
PiperOrigin-RevId: 165596223
|
|
|
|
|
|
|
|
| |
Dynamic configs use RuleTransitionFactory instead.
Part of the static config cleanup effort.
PiperOrigin-RevId: 165590679
|
|
|
|
|
|
| |
as a pilot. Currently not hooked up to anything, but will be shortly.
PiperOrigin-RevId: 165583517
|
|
|
|
| |
PiperOrigin-RevId: 165581746
|
|
|
|
| |
PiperOrigin-RevId: 165578449
|
|
|
|
|
|
|
| |
This is a simple refactoring, no change in behavior.
RELNOTES: None.
PiperOrigin-RevId: 165572028
|
|
|
|
| |
PiperOrigin-RevId: 165571541
|
|
|
|
|
|
|
|
|
| |
command to CMD.EXE.
Fix https://github.com/bazelbuild/bazel/issues/2040#issuecomment-322980147
RELNOTES: None
PiperOrigin-RevId: 165562681
|
|
|
|
|
|
|
| |
We rarely need it, it's not useful to keep it in memory.
RELNOTES: None.
PiperOrigin-RevId: 165562119
|
|
|
|
|
|
|
|
|
| |
of the configuration in genrules.
This is necessary because if one uses a java_runtime rule that has java_home="$(VAR") and VAR is set to an absolute path, BuildConfiguration won't be able to resolve VAR (since it's a Make variable and thus can't affect other Make variables), Blaze won't be able to tell that it's an absolute value and thus will prepend the package name of the java_runtime rule to it, e.g. resulting in a//foo/bar instead of /foo/bar if the java_runtime rule is in package a.
RELNOTES: None.
PiperOrigin-RevId: 165555251
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
host configuration.
I think the comment I'm deleting is misleading. PAR file construction
already has special handling of the input manifest, and host tools do
get their runfiles when executed remotely. They don't get them for
local execution, but users who care about that don't need to pass the
non-default --nobuild_runfile_links option.
RELNOTES: None.
PiperOrigin-RevId: 165535870
|
|
|
|
|
|
|
|
|
|
| |
roots
It also changes a few accessors of utility methods in Skyframe library. It
refactors the QueryExpressionMapper to use a general QueryExpressionVisitor.
RELNOTES: None
PiperOrigin-RevId: 165534908
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 165489091
|
|
|
|
|
|
|
| |
is a target.
RELNOTES: None
PiperOrigin-RevId: 165482057
|
|
|
|
| |
PiperOrigin-RevId: 165478994
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 165477209
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 165469671
|
|
|
|
|
| |
RELNOTES: Top-level `if` statements are now forbidden.
PiperOrigin-RevId: 165469101
|
|
|
|
|
|
|
|
| |
After this change, it will be easier to move the validate() methods to a
separate visitor.
RELNOTES: None.
PiperOrigin-RevId: 165467838
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 165465128
|
|
|
|
|
|
| |
Fixes #3329.
PiperOrigin-RevId: 165443367
|
|
|
|
|
|
|
|
|
|
| |
As part of the migration away from android_resources, add a flag that causes
failures if android_resources is encountered. This makes it easier to test that
all android_resources targets have been removed without actually breaking any
builds.
RELNOTES: none
PiperOrigin-RevId: 165437983
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 165434934
|
|
|
|
|
|
|
| |
A bug was introduced in patch 9626bb4923c74c6d3c09b7438eb24b32191053df, where a cache miss would not result in action re-execution, making the cache miss non-recoverable.
RELNOTES: fixes #3552
PiperOrigin-RevId: 165434579
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 165422514
|
|
|
|
|
|
|
| |
disk have changed since it was launched, print *which* files have changed.
RELNOTES: Improved logging when workers have to be restarted due to its files having changed.
PiperOrigin-RevId: 165419664
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 165419360
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allowing add(Object) is too loose and can easily lead to programmer mistakes.
Because of type erasure, we can't use the same overload name for (eg.) add(NestedSet<String>) and add(NestedSet<Artifact>). The API is overhauled to use the same terms everywhere, eg. "add", "addPaths", "addExecPaths". This is similar to how it used to be a few CLs ago.
The API is overhauled to make sure it's consistent for all types. While tedious, the facade methods immediately dispatch to internal helpers, so implementation wise it's not too heavy.
While large, this CL is almost entirely an automated refactor.
PiperOrigin-RevId: 165358287
|
|
|
|
|
|
| |
replace the startup option after a deprecation period.
PiperOrigin-RevId: 165340514
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows us to perform a more gradual migration away from the
android_resources rule. Specifically, rather than move all android_resources
targets and simultaneously move all resources attributes, we can now first
transform all android_resources rules into android_library rules, and then
afterwards migrate dependencies on those rules from resources into deps. This
allows a two-part migration.
The resources attribute, once allowed to take android_library targets, should
continue to work exactly as before.
There is one change in behavior - for this to work, android_library targets now
need to build an output APK during resource processing. This APK will be
removed once the resources attribute is removed.
Once the migration is complete, the resources attribute will be removed
completely.
RELNOTES: none
PiperOrigin-RevId: 165313447
|