| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
The memory regression was introduced in https://github.com/bazelbuild/bazel/commit/360fb4d9a1e2c44154b17aeb866e07bac2dd1b5b , now default providers
are optimized and are built only on demand for all types of targets.
PiperOrigin-RevId: 152957220
|
|
|
|
|
|
|
| |
This follows our CamelCaseInfo naming conventions for providers.
RELNOTES: None.
PiperOrigin-RevId: 152832215
|
|
|
|
|
|
|
| |
Default providers can now be used not only to return standard providers values
from a rule implementation function, but also to access these values provided
by other rules.
PiperOrigin-RevId: 152797193
|
|
|
|
|
|
|
|
| |
If aspect a3 sees aspect a2, and aspect a2 sees aspect a1, propagation
of the aspect list [a1,a2,a3] should not lose any aspects.
RELNOTES: None.
PiperOrigin-RevId: 152786900
|
|
|
|
|
|
|
|
| |
In this way, shared subsets of artifacts are only reported once,
even if occurring for many aspect-target pairs.
Change-Id: Ia300126f427af4a9cc630fbfca649760d8b72262
PiperOrigin-RevId: 152692099
|
|
|
|
|
|
|
|
| |
To avoid artifacts rolled up from other targets to be reported several
times.
Change-Id: I8a329f1c53ad3fcb37cc6602b906472dfce1a12f
PiperOrigin-RevId: 152688681
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
PiperOrigin-RevId: 152307322
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
'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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--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
|
|
|
|
|
|
|
|
| |
in Skylark.
RELNOTES: None.
PiperOrigin-RevId: 151744710
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
RuleTransitionFactory#buildTransitionFor is @Nullable, but the
SkyframeExecutor expects a non-null Transition. If the factory
returns null, the SkyframeExecutor should be passed NONE, not null.
PiperOrigin-RevId: 151615724
|
|
|
|
|
|
|
|
|
|
| |
If a rule requires a special provider that's (maybe) not provided explicitly
but nevertheless available from a target, i.e. "files", the mandatory providers
check should pass.
Fixes #1490
PiperOrigin-RevId: 151571187
|
|
|
|
|
|
|
|
| |
ConfiguredTargetValues. Also clear transitive packages for both, even for top-level targets.
This is not expected to save significant memory, but is expected to reduce the number of references to Packages, allowing them to be dropped more easily when discarding analysis cache and running in batch mode.
PiperOrigin-RevId: 151508877
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 151170448
MOS_MIGRATED_REVID=151170448
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 151129669
MOS_MIGRATED_REVID=151129669
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's now allowed to return anything from a rule implementation function.
If a ctx object is returned it becomes featureless and cannot be used from
anywhere else (i.e. from an implementation function of another rule).
Fixes #2319
--
PiperOrigin-RevId: 151015919
MOS_MIGRATED_REVID=151015919
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, a stamped bazel binary contains the actual timestamp at build
time. This means, that building bazel we either include no version
information at all, or the binary contains a not reproducible time
stamp. Both are not acceptable from the point of view of a downstream
maintainer of a bazel package, where the requirement is that the package
be reproducible, but the binary still provide sensible version information.
Fortunately, there is a suggested standard to solve this problem taking
the "current time" from the SOURCE_DATE_EPOCH environment variable, if
set, rather than the actual time.
See https://reproducible-builds.org/specs/source-date-epoch/.
Honor this proposed standard, so that bazel can reasonably be packaged
downstream. See issue #2240.
Note that we only use the environment variable in our bootstrap script;
for bazel itself we communicate that information via an appropriate
option.
--
Change-Id: I55409a117285b9a3446421179c20f4e8c59088f8
Reviewed-on: https://cr.bazel.build/9467
PiperOrigin-RevId: 150896326
MOS_MIGRATED_REVID=150896326
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 150869561
MOS_MIGRATED_REVID=150869561
|
|
|
|
|
|
|
|
|
|
|
|
| |
This begins to allow for cases where a rule sets configuration
based on its attributes, such as where a rule attribute names
flags and their values - sort of a reverse select.
There are no such cases yet, but they're coming!
--
PiperOrigin-RevId: 150648357
MOS_MIGRATED_REVID=150648357
|
|
|
|
|
|
|
|
|
|
|
| |
This now also checks symlink maps for null pointers, which it previously did
not. Unfortunately, there's still one case where we add a null target to
Runfiles (to represent an empty file) - this happens in Runfiles itself, and
this change prevents any callers from doing so.
--
PiperOrigin-RevId: 150634481
MOS_MIGRATED_REVID=150634481
|
|
|
|
|
|
|
|
|
|
| |
Add preconditions to enforce this and remove some now unnecessary code.
A small step towards #1593.
--
PiperOrigin-RevId: 150625693
MOS_MIGRATED_REVID=150625693
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 150623623
MOS_MIGRATED_REVID=150623623
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Break bazel-tests and many other jobs on CI.
http://ci.bazel.io/job/bazel-tests/BAZEL_VERSION=HEAD,PLATFORM_NAME=linux-x86_64/651/console
*** Original change description ***
Add SpawnInputExpander helper class to arrange runfiles for spawn strategies
This new class is a combination of SpawnHelper and our internal code; the
plan is to migrate all spawn strategies to the new class. The strict flag
should be enabled by default, but that's a breaking change, so we need to do
it later.
- Use it in SandboxStrategy.
- Add ActionInput.getExecPath to return a PathFragment; this avoids lots of
back and forth between path fragments and strings.
This is a step towards #159...
***
--
PiperOrigin-RevId: 150610616
MOS_MIGRATED_REVID=150610616
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is intended to be used for "flags" which should never appear on the
command line - things like configuration distinguishers, which are used
internally and must be part of the build options, but should always be set
to their default value at the top level.
This is already a convention within Bazel, but doesn't actually work the way
Bazel expects - flags with spaces can be set by simply escaping or quoting
the spaces so that word splitting will not break on them. This means they
can also be matched by config_settings, which pass a single string.
Forbidding the parser from matching these flags solves both of these
unintended cases.
Existing cases like this have also been converted to internal.
--
PiperOrigin-RevId: 150497246
MOS_MIGRATED_REVID=150497246
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new class is a combination of SpawnHelper and our internal code; the
plan is to migrate all spawn strategies to the new class. The strict flag
should be enabled by default, but that's a breaking change, so we need to do
it later.
- Use it in SandboxStrategy.
- Add ActionInput.getExecPath to return a PathFragment; this avoids lots of
back and forth between path fragments and strings.
This is a step towards #1593.
--
PiperOrigin-RevId: 150427021
MOS_MIGRATED_REVID=150427021
|
|
|
|
|
|
|
|
|
|
|
|
| |
In particular, emphasize that that both, the static and dynamic part of
the configuration has to be collected to get the environment to be used
by actions.
--
Change-Id: I035def947d06dbd8f58460b5bf293b35a8ae038c
Reviewed-on: https://cr.bazel.build/9373
PiperOrigin-RevId: 150319122
MOS_MIGRATED_REVID=150319122
|
|
|
|
|
|
|
|
| |
--
Change-Id: I3221e27e99c740b8ff2bdec8c242cc5cf30c16b5
Reviewed-on: https://cr.bazel.build/9375
PiperOrigin-RevId: 150229108
MOS_MIGRATED_REVID=150229108
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this way, we can also report the artifacts generated
by aspects in the build event protocol.
For the time being, those events are reported unsolicitly
(i.e., as children of progress events), but they may be linked
to pattern expansion later.
--
Change-Id: I7fb83088d7fdb5424f77bfb78700e8371231b13c
Reviewed-on: https://cr.bazel.build/9370
PiperOrigin-RevId: 150181433
MOS_MIGRATED_REVID=150181433
|
|
|
|
|
|
|
|
| |
annotations.
--
PiperOrigin-RevId: 150088575
MOS_MIGRATED_REVID=150088575
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically:
1) Read BuildOptions instead of BuildConfiguration
2) Remove unused extra parameters
1) is especially useful for dynamic configs. Before this change, dynamic configs just didn't support attribute configurators. This is because support would require Skyframe-instantiating temporary intermediate configurations, which is horribly awkward and would massively complicate Bazel's dependency evaluation logic. Using BuildOptions instead of BuildConfiguration completely eliminates the problem.
As a bonus, dynamic configs can compose attribute configurators with any other transitions (including splits). This actually makes them more powerful than static configs. Whether anyone wants to use that composition is a different story, but that's now a policy decision vs. a technical limitation. This should also come in handy for RuleClass configurators, which will likely also leverage this.
--
PiperOrigin-RevId: 150080977
MOS_MIGRATED_REVID=150080977
|
|
|
|
|
|
|
|
| |
This became necessary because extra actions for C++ compile actions require .h files, but the compiler only returns the .pcm files in the .d file for headers that it reads from the .pcm file. This is not a problem for correctness because the .pcm files depend on the headers, but that doesn't help the extra actions that would then only get the .pcm files.
--
PiperOrigin-RevId: 150052839
MOS_MIGRATED_REVID=150052839
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 149439502
MOS_MIGRATED_REVID=149439502
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 149165836
MOS_MIGRATED_REVID=149165836
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 149110466
MOS_MIGRATED_REVID=149110466
|
|
|
|
|
|
|
|
|
|
|
|
| |
I was fixing the Android tests and I noticed that the bazel_workspace_status_test was failing. It was like when you have a thread coming out of a sweater and you start pulling and pretty soon you have no sweater. Long story short, my "Android tests fix" cl ended up needing ~1k more lines changed (on top of the existing enormous CL).
So, I'm creating some smaller CLs with the changes that I can extract from the mega CL. Again.
Prep for #1681.
--
PiperOrigin-RevId: 149106039
MOS_MIGRATED_REVID=149106039
|
|
|
|
|
|
|
|
| |
Fixes #2016
--
PiperOrigin-RevId: 149102037
MOS_MIGRATED_REVID=149102037
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) Instead of having a single class for both, split them into
{Skylark,Native}ClassObjectConstructors
2) Allow NativeClassObjectConstructors to customize their instantiation
logic.
3) Prepare ClassObjectConstructor.Key to be serializable.
--
PiperOrigin-RevId: 148997553
MOS_MIGRATED_REVID=148997553
|
|
|
|
|
|
|
|
|
|
|
| |
provide a provider.
Previously we always executed the function, but didn't add the aspect to
the deps.
--
PiperOrigin-RevId: 148887089
MOS_MIGRATED_REVID=148887089
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A target's tags and output files are reported as part of
the TargetComplete event of the build event protocol (BEP).
The output files are grouped by their corresponding output
group. If an output file belongs to more than one output group
it appears once in each output group.
--
Change-Id: Ia37db68709850d8550e478dcc30064dc7366bd1b
Reviewed-on: https://cr.bazel.build/8955
PiperOrigin-RevId: 148667599
MOS_MIGRATED_REVID=148667599
|
|
|
|
|
|
|
|
| |
to generate extra action proto file.
--
PiperOrigin-RevId: 148479293
MOS_MIGRATED_REVID=148479293
|