| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(Automated g4 rollback of commit de92f9d8ea093416fae999073bbfcf3cf501ab55).
*** Reason for rollback ***
The problems that forced commit de92f9d8ea093416fae999073bbfcf3cf501ab55 were fixed in commit e6392cd380fce14d719890c78d5eb2657e8a6cfc .
*** Original change description being rolled forward ***
Implement dynamically configured LIPO builds.
Quick overview:
- provide a dynamic interface for getting the artifact owner
configuration
- provide a (dynamic) RuleTransitionFactory LIPO_ON_DEMAND to replace
the (static) RuleClass.Configurator LIPO_ON_DEMAND. Eventually
we'll remove the rule class configurator interface entirely....
***
ROLLBACK_OF=156180015
PiperOrigin-RevId: 157865224
|
|
|
|
|
|
|
|
| |
This also guarantees consistency between toString()
calls to lib.syntax.SelectorList and
lib.packages.BuildType.SelectorList.
PiperOrigin-RevId: 157617509
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This cl introduces new action_config type for Crosstool named 'generic'. This
can be used to set the value of CC_FLAGS make variable using much more
expressive mechanism (action_configs + features) than previous make_variable
Crosstool messages. This has been requested by the C++ LPT.
However, as FeatureConfiguration needs RuleContext, CC_FLAGS cannot be
computed using configuration only anymore. Also, FeatureConfiguration is C++
rules specific class, and Bazel build-base cannot depend on it. Therefore we
cannot use FeatureConfiguration for ExtraActions, for example. Because it cannot
be made perfect, this cl is not updating all the possible places that expand
make variables but limits the scope to:
* genrule (the only widely used rule that often expands make variables)
* *_test (CC_FLAGS is used by Tensorflow in the 'args' attribute)
* cc_rules (people sometimes set 'copts' to something like:
"-DCC_STRING=\\\"$(CC)\\\" -DCC_FLAGS_STRING=\"$(CC_FLAGS)\""
The long term plan is to use Skylark C++ API to get C++ command lines, so
CC_FLAGS together with this inconsistent solution will be removed.
RELNOTES: CC_FLAGS can be defined using 'generic' action_config in CROSSTOOL
PiperOrigin-RevId: 157202883
|
|
|
|
|
| |
Change-Id: I0604355801bd7e4f77a93bfc38e970713a1392c5
PiperOrigin-RevId: 157116222
|
|
|
|
|
|
|
| |
Part of #2219.
Change-Id: I39ced1f3e2605154771df9424d6ed2f971820baf
PiperOrigin-RevId: 157002268
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Roll forward of directory name change
*** Original change description ***
Automated g4 rollback of commit 1d9e1ac90197b1d3d7b137ba3c1ada67bb9ba31b.
*** 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: 156892980
|
|
|
|
|
|
|
|
| |
This doesn't really expose new information, because one can iterate over the existing getTargets() and recreate the map.
Moreover, the map is immutable, so there's no risk in returning it to the user.
RELNOTES: None
PiperOrigin-RevId: 156349797
|
|
|
|
|
|
|
|
| |
Also expose both sides to Skylark.
Part of #2219.
Change-Id: I4d749dd9981fe33f75310acb0ec3927cff6f28fe
PiperOrigin-RevId: 156340638
|
| |
|
|
|
|
|
|
|
|
|
|
| |
ToolchainConstructor is used to create instances of ToolchainInfo, for
toolchain-aware rule sets.
Part of #2219.
Change-Id: Iae4e519b156910cc28704b3ca5b11e57dd561107
PiperOrigin-RevId: 156303854
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Causes crash bug in certain circumstances.
*** Original change description ***
Implement dynamically configured LIPO builds.
Quick overview:
- provide a dynamic interface for getting the artifact owner
configuration
- provide a (dynamic) RuleTransitionFactory LIPO_ON_DEMAND to replace
the (static) RuleClass.Configurator LIPO_ON_DEMAND. Eventually
we'll remove the rule class configurator interface entirely.
This doesn't actually turn dynamic LIPO on. So the direct effect of
this change should be a no-op. The flip will come in a followup
change. For now, dynamic...
PiperOrigin-RevId: 156180015
|
|
|
|
|
|
|
|
|
| |
Make fields visibility/accessors more idiomatic. Prefer accessors that give a full map of the bindings and inherited bindings, rather than just the keys.
Also increase visibility of some accessors on Mutability.
RELNOTES: None
PiperOrigin-RevId: 155393780
|
|
|
|
| |
PiperOrigin-RevId: 155194438
|
|
|
|
|
|
|
|
| |
Also, repository_name() replaces REPOSITORY_NAME.
In .bzl files, they are prefixed with "native.".
RELNOTES: None.
PiperOrigin-RevId: 155102221
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Quick overview:
- provide a dynamic interface for getting the artifact owner
configuration
- provide a (dynamic) RuleTransitionFactory LIPO_ON_DEMAND to replace
the (static) RuleClass.Configurator LIPO_ON_DEMAND. Eventually
we'll remove the rule class configurator interface entirely.
This doesn't actually turn dynamic LIPO on. So the direct effect of
this change should be a no-op. The flip will come in a followup
change. For now, dynamic LIPO can be triggered with
--experimental_dynamic_configs=notrim.
PiperOrigin-RevId: 155096056
|
|
|
|
|
|
|
|
|
| |
This is a standalone library for loading packages. It is intended to be used by clients outside of Bazel (for now, Kythe).
Perform BazelPackageLoader#loadPackage in the testing hook used in all of Bazel's unit tests and integration tests. This gives us very good test coverage for BazelPackageLoader.
RELNOTES: None
PiperOrigin-RevId: 155004070
|
|
|
|
|
|
|
|
| |
Add static methods to return target kinds of InputFile and OutFile, as well as
suffix of target kind of Rule.
RELNOTES: None
PiperOrigin-RevId: 154866926
|
|
|
|
|
|
|
|
|
|
|
| |
This is the second of two CLs for making command line options able to affect the Skylark interpreter. For the main kinds of evaluation contexts -- package loading, .bzl loading, rule analysis, aspect analysis, and computed defaults -- the SkylarkSemanticsOptions object is retrieved from Skyframe and passed along to the Environment builder. For other contexts such as tests, default values of builtin functions, and standalone Skylark, flags are currently not processed.
In the future, we may want to split into separate files the options that affect "pure" Skylark vs the options that affect Bazel-flavored Skylark. One possibility is to subclass SkylarkSemanticsOptions into SkylarkBazelSemanticsOptions, and go through an indirection in SkylarkUtils.
We could also pass SkylarkSemanticsOptions to the parser, to support --incompatible_* changes that alter Skylark's syntax. I don't think that's needed at the moment.
RELNOTES: None
PiperOrigin-RevId: 154628391
|
|
|
|
|
|
|
| |
Only works for top-level targets.
RELNOTES: None.
PiperOrigin-RevId: 154176914
|
|
|
|
|
| |
Change-Id: Ifdc1773fb1439c16327bb84961998793a942e666
PiperOrigin-RevId: 154151084
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 153058374
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fa97703c1edf ("allow skylark implicit output callbacks to use the rule
name") fixed a limitation of the skylark implicit outputs by adding a
special case for "name" to the implicit outputs code. Later,
015e5954157a ("Remove special handling of name attribute") fixed the
general problem of "name" being a special case in the attribute
map. Therefore, we can remove my original fix. We may also excise an
older special case in the implicit outputs templating code.
Change-Id: I606c9decd98a8df492d2359abe540d3263f99fe1
PiperOrigin-RevId: 152974774
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 152965874
|
|
|
|
| |
PiperOrigin-RevId: 152916191
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 152882585
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 152804937
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 152800780
|
|
|
|
| |
PiperOrigin-RevId: 152412325
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 152386957
|
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 152291766
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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
|
|
|
|
|
|
|
|
| |
outputFiles and outputFileMap objects in Rule.
RELNOTES: None.
PiperOrigin-RevId: 151764143
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
This isn't used anymore, it's the same as STRING_DICT, deleting so no one tries
to use it.
PiperOrigin-RevId: 151738915
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 151170448
MOS_MIGRATED_REVID=151170448
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(like %{invalid}) in implicit outputs.
SkylarkImplicitOutputsFunctionWithMap.calculateOutputs now throws
an EvalException in case of invalid placeholders in com.google. \
devtools.build.lib.packages.ImplicitOutputsFucntion.
Fix #2467 on Github
--
Change-Id: I5460388d0b3f83390aed4c45c967c633c2574e3b
Reviewed-on: https://cr.bazel.build/9490
PiperOrigin-RevId: 150907001
MOS_MIGRATED_REVID=150907001
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 150675067
MOS_MIGRATED_REVID=150675067
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 150051360
MOS_MIGRATED_REVID=150051360
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 149169656
MOS_MIGRATED_REVID=149169656
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 149165836
MOS_MIGRATED_REVID=149165836
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 148643993
MOS_MIGRATED_REVID=148643993
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With more specific information to be reported by Skyfunctions, e.g.,
to inform the build-event protocol on missing files, the EventHandler
interface is no longer enough. Therefore, provide an enriched context
for reporting events.
--
Change-Id: I2d06166fe4d5b9054e24ad8c752fafc039e3f9f8
Reviewed-on: https://cr.bazel.build/8794
PiperOrigin-RevId: 148463437
MOS_MIGRATED_REVID=148463437
|