| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
--
MOS_MIGRATED_REVID=135689610
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=135458547
|
|
|
|
|
|
|
|
|
|
| |
instead of "and".
Also allow native rules to require declared providers on their
dependencies.
--
MOS_MIGRATED_REVID=135454750
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=134652924
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks TensorFlow and other Bazel jobs on ci.bazel.io
*** Original change description ***
Change execution root for external repositories to be ../repo
Some of the important aspect of this change:
* Remote repos in the execution root are under output_base/execroot/repo_name, so the prefix is ../repo_name (to escape the local workspace name).
* Package roots for external repos were previously "output_base/", they are now output_base/external/repo_name (which means source artifacts always have a relative path from their repository).
* Outputs are under bazel-bin/external/repo_name/ (or similarly under genfiles). Note that this is a bit of a change from how this was implemented in the previous cl.
Fixes #1262.
RELNOTES[INC]: Previously, an external repository would be symlinked into the
execution root at execroot/local_repo/external/remote_repo. This changes it to
be at execroot/remote_repo. This may break genrules/Skylark actions that
hardcode execution root paths. If this causes breakages for you, ensure that
genrules are using $(location :target) to access files and Skylark rules are
using http://bazel.io/docs/skylark/lib/File.html's path, dirname, etc.
functions.
Roll forward of bdfd58a.
--
MOS_MIGRATED_REVID=133709658
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some of the important aspect of this change:
* Remote repos in the execution root are under output_base/execroot/repo_name, so the prefix is ../repo_name (to escape the local workspace name).
* Package roots for external repos were previously "output_base/", they are now output_base/external/repo_name (which means source artifacts always have a relative path from their repository).
* Outputs are under bazel-bin/external/repo_name/ (or similarly under genfiles). Note that this is a bit of a change from how this was implemented in the previous cl.
Fixes #1262.
RELNOTES[INC]: Previously, an external repository would be symlinked into the
execution root at execroot/local_repo/external/remote_repo. This changes it to
be at execroot/remote_repo. This may break genrules/Skylark actions that
hardcode execution root paths. If this causes breakages for you, ensure that
genrules are using $(location :target) to access files and Skylark rules are
using http://bazel.io/docs/skylark/lib/File.html's path, dirname, etc.
functions.
Roll forward of bdfd58a.
--
MOS_MIGRATED_REVID=133606309
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently aspects have no tag, i.e., they don't get checked against output
filters at all. This changes aspects to have a tag of the same form as the
rule they are attached to (i.e., the label of the target).
Since the default output filters match on ^//package[:/], this should cover
most uses of the output filter, while still allowing for finer control for
those who crave it.
--
MOS_MIGRATED_REVID=133425215
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases, Bazel has already been doing this.
In other cases, Bazel tried to infer the default cpu from the CROSSTOOL, but it
did not do so consistently across different configuration fragments. I.e.,
Bazel ended up with an inconsistent set of toolchains for e.g., Python, C++,
and Java.
After this change, Bazel ignores any default_cpu setting in the CROSSTOOL.
Note that the Jvm is still inconsistent with all others, as it uses "default"
as the cpu value and ignores both command-line-specified and CROSSTOOL-specified
values.
--
MOS_MIGRATED_REVID=132879102
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=132464865
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is so that the repository name can be included in the root.
To avoid breaking Bazel's CI which tests the HEAD code against the latest
release, none of the Skylark rules in Bazel can be updated to use
ctx.{bin,genfiles}_dir yet, we will have to wait for the 0.3.2 release to
actually update the call sites. However, this change is to effectively
deprecate ctx.configuration.{bin,genfiles}_dir: it undocuments them and I will
announce the change on the list.
RELNOTES[INC]: bin_dir and genfiles_dir are now properties of ctx, not
configuration. That is, to access the bin or genfiles directory from a
Skylark rule, use ctx.bin_dir or ctx.genfiles_dir (not
ctx.configuration.{bin,genfiles}_dir). At the moment, you can access
{bin,genfiles}_dir from either, but the ctx.configuration version will
stop working in a future release.
--
MOS_MIGRATED_REVID=132319900
|
|
|
|
|
|
|
| |
RELNOTES: Reverts a change that lead to misleading warnings.
--
MOS_MIGRATED_REVID=132230645
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=131379356
|
|
|
|
|
|
|
| |
The only place we now don't handle InterruptedException is in the action graph created after analysis, since I'm not sure that will be around for that much longer.
--
MOS_MIGRATED_REVID=130327770
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OrderedSetMultimap. This maintains insertion order while eliminating duplicates.
Certain rules, in particular, otherwise break this invariant:
https://github.com/bazelbuild/bazel/blo[]e3e28274cca5b87f48abe33884edb84016dd3/src/main/java/com/google/devtools/build/lib/skyframe/ConfiguredTargetFunction.java#L403
There's no reason (to my knowledge) to need multiple instances of the same <Attribute, Dependency> pair.
More context from Google code review:
(Michael Staib):
> There are many things which pass around a dependentNodeMap or help construct one or modify one. We want an interface which has the right guarantees.
> ListMultimap is not the right interface because it has no guarantee of unique elements, which we want - we don't want the problem that this CL ran into, and there's no reason (that we know of, to be confirmed) that anyone would want multiple identical Dependencies.
> SetMultimap is not the right interface because it has no guarantee of deterministic iteration order or efficient iteration, which we want - dependency order sometimes matters (e.g., Java classpath or C++ link order).
> We agreed that the best way to get what we want is to define our own interface with its own simultaneous uniqueness and iterability guarantees. Unspoken in the discussion was why we wouldn't just use LinkedHashMultimap as the thing we pass around. IMO the reason for that is that we don't care that it be a LinkedHashMultimap specifically; if tomorrow Guava comes out with a faster cooler map that has deterministic and efficient iteration and guarantees element uniqueness, we want it.
> In this case we're going to make the "interface" be a (final?) class: OrderedSetMultimap, an extension of ForwardingSetMultimap which delegates to LinkedHashMultimap, an implementation which does support both of those guarantees.
> I had mentioned in the conversation that none of the Multimap implementations make guarantees about key iteration order, but this is not true - LinkedHashMultimap preserves key insertion order. We should perhaps declare this as part of the OrderedSetMultimap contract as well.
--
MOS_MIGRATED_REVID=130037643
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This doesn't do anything yet, it's in preparation for the execroot rearranging
change. The execroot will have one bazel-out per repo, so it'll look like:
execroot/
repo1/
bazel-out/
local-fastbuild/
bin/
repo2/
bazel-out/
local-fastbuild/
bin/
genfiles/
repo3/
bazel-out/
local-fastbuild/
testlogs/
and so on. Thus, any output path (getBinDirectory() & friends) needs to know
what the repo name is. This changes so many places in the code I thought it
would be good to do separately, then just flip the functionality in the
execroot-rearranging commit.
While I was poking around, I changed all of the refs I could from getPackageRelativeArtifact() to getBin/GenfilesArtifact(), so that 1) rule implementation don't have to know as much about roots and 2) they'll be more isolated from other output dir changes.
`bazel info` and similar just return roots for the main repository.
The only "change" is passing around a target label in the Java rules.
Continues work on #1262.
--
MOS_MIGRATED_REVID=129985336
|
|
|
|
|
|
|
|
|
|
| |
With the prereq work behind this, this is surprisingly straightforward. The main change
is to eliminate BuildConfiguration.SplittableTransitionApplier, make both DynamicTransitionApplier and StaticTransitionApplier split-aware, and add awareness of this to ConfiguredTargetFunction.trimConfigurations.
Latebound splits will follow next.
--
MOS_MIGRATED_REVID=129480309
|
|
|
|
|
|
|
|
|
|
|
| |
This change was motivated by a need to write pure Skylark rules that expose their own objc providers so they can be used as deps to other libraries/application targets (e.g., SceneKit/SpriteKit compiled resources, []) without having to whitelist them and wait for a Blaze release.
This CL fixes what seems to be a bug in validateRuleDependency, where the behavior in the doc comment implies that it will accept a whitelisted rule name *or* a list of mandatory providers, but as implemented today it seems to require the rule to be whitelisted even if the mandatory native providers matched.
RELNOTES: objc_* rules can now depend on any target that returns an "objc" provider.
--
MOS_MIGRATED_REVID=128835096
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
execroot change
This is in prep for making the execution root path for external repositories
../repo_name (instead of external/repo_name). Right now, the getRunfilesPath() returns that path, so that is renamed getExecRoot() (since the runfiles are really just a reflection of the execRoot structure). getSourceRoot() replaces getPathFragment, which has always been a confusing name (it's not clear from the name
what the difference is between it and getPackageFragment()). It returns the relative path to source files for external repositories (external/repo_name).
Also renamed/moved to more sensible class a few static RepositoryName fields.
--
MOS_MIGRATED_REVID=128594419
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=128184440
|
|
|
|
|
|
|
| |
Instead have callers get it via package.
--
MOS_MIGRATED_REVID=127715494
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Broke Android targets with native code when cpu is explicitly set.
*** Original change description ***
RELNOTES: Improve Android split transition handling.
--
MOS_MIGRATED_REVID=127377943
|
|
|
|
|
|
|
| |
This is necessary because we don't have a replacement for saying "this genrule needs the C++ toolchain" and I'd prefer this to do it in a backward-compatible way; burned myself here by trying to be principled, so let's now do the pragmatic thing.
--
MOS_MIGRATED_REVID=127317024
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=127099896
|
|
|
|
|
|
|
| |
Android split transitions.
--
MOS_MIGRATED_REVID=126378169
|
|
|
|
| |
MOS_MIGRATED_REVID=125712280
|
|
|
|
|
|
|
|
|
| |
This builds all dependencies linked against watch SDKs instead of iOS SDKs, and builds for the architectures specified in --watchos_multi_cpus
RELNOTES: apple_binary supports a new platform_type attribute, which, if set to "watchos", will build dependencies for Apple's watchOS2.
--
MOS_MIGRATED_REVID=124980029
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When true (the default), test rules included by --instrumentation_filter are instrumented. When false, test rules are excluded from instrumentation (whether or not their names would be matched by --instrumentation_filter).
This option provides a superior way to exclude test rules from instrumentation, compared to setting --instrumentation_filter exclusions based on test rule naming conventions. Naming conventions vary from language to language and are not always followed. Blaze already has enforced semantics for test targets (test rule build function names _must_ end in "_test", see TargetUtils.isTestRule). In general, when either option is available, it's better to rely on enforced semantics than unenforced conventions.
Note that this default preserves present behavior. In the future, I think it would make sense to:
* Change the default value of --instrument_test_targets to false.
* Change the default value of --instrumentation_filter to an empty string (match everything).
RELNOTES: Add --instrument_test_targets option.
--
MOS_MIGRATED_REVID=124732226
|
|
|
|
|
|
|
|
|
|
| |
instead of passing and checking null in all helpers.
Demonstrates this pattern usage in a few select rules (e.g. AndroidBinary) where this was particularly egregious.
There are many places which can benefit from this pattern -- this change doesn't try to fix them all at once.
--
MOS_MIGRATED_REVID=123012378
|
|
|
|
|
|
|
| |
to it.
--
MOS_MIGRATED_REVID=122718503
|
|
|
|
|
|
|
| |
allowed but with a warning" messages.
--
MOS_MIGRATED_REVID=122194162
|
|
|
|
|
|
|
| |
This will be used to replace RedirectChaser so that we don't need to load packages during configuration creation anymore.
--
MOS_MIGRATED_REVID=121935989
|
|
|
|
|
|
|
|
|
| |
select() is the new abi_deps.
RELNOTES[INC]: Removed cc_* attributes: abi / abi_deps. Use select() instead.
--
MOS_MIGRATED_REVID=121704422
|
|
|
|
|
|
|
| |
and use it to validate that :java_toolchain has a JavaToolchainProvider.
--
MOS_MIGRATED_REVID=121396726
|
|
|
|
|
|
|
| |
can be added to by fragments. Uses the registry to enable native access to TranstiveProviderInstances from Skylark. In particular, makes ObjcProvider accessible to skylark rule implementations.
--
MOS_MIGRATED_REVID=121390911
|
|
|
|
|
|
|
| |
configurations of the split transition
--
MOS_MIGRATED_REVID=121146341
|
|
|
|
|
|
|
| |
Except in action execution logic (ActionExecutionFunction, SkyframeActionExecutor, etc.), switch Action interface references to either ActionAnalysisMetadata if possible or ActionExecutionMetadata.
--
MOS_MIGRATED_REVID=120723431
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=120433463
|
|
|
|
|
|
|
| |
attribute based on the Rule itself (the transition may thus be determined based on the values of other attributes of the rule)
--
MOS_MIGRATED_REVID=120275649
|
|
|
|
|
|
|
|
| |
Consists of adding @Immutable annotations, adding final modifiers, and changing
the types of fields to immutable types.
--
MOS_MIGRATED_REVID=120221067
|
|
|
|
|
|
|
| |
rolled back in commit 1250fdac4c7769cfa200af8b4f9b061024356fea. There was nothing wrong with that change.
--
MOS_MIGRATED_REVID=119756383
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
--
MOS_MIGRATED_REVID=119625653
|
|
|
|
|
|
|
|
|
| |
configuration.
This is useful for obtaining child split configurations and the information they provide.
--
MOS_MIGRATED_REVID=119295699
|
|
|
|
|
|
|
| |
proto-compiler use a params file.
--
MOS_MIGRATED_REVID=119193368
|
|
|
|
|
|
|
| |
question, rather than during loading of the target's package. This way a target's package won't be in error if e.g. an unrelated target has empty 'srcs'.
--
MOS_MIGRATED_REVID=119079777
|
|
|
|
|
|
|
| |
accidentally keep references to them after the analysis phase.
--
MOS_MIGRATED_REVID=117855145
|
|
|
|
|
|
|
|
|
| |
basically doing the same thing with it.
This simplifies the code and avoids unnecessary re-wrapping, which saves memory.
--
MOS_MIGRATED_REVID=117693050
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=117583615
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using mandatoryProvidersList to validate python rules' dependency.
Added a SkylarkProvider named 'py' which is a SkylarkClassObject in Java and a
struct in Skylark. Native python rule and Skylark python rule should have this provider
so that they can depend on each other.
RELNOTES[NEW]: Native python rule can depend on skylark rule as long as skylark
rule provides 'py' provider.
--
MOS_MIGRATED_REVID=116241504
|
|
|
|
|
|
|
|
| |
"mandatoryProvidersList" is a list of sets of providers. For any rule, if it provides
all the providers from one of those sets, we consider the dependency valid.
--
MOS_MIGRATED_REVID=115221394
|
|
|
|
|
|
|
| |
implemented yet.
--
MOS_MIGRATED_REVID=114157140
|