| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we receive an event indicating that the build is over, we first
post that event and then clear up all pending event by stating that
their prerequisite event was aborted (which we can safely assert, as
we know we will not process any further events).
Now, if a build is aborted (e.g., user interruption) before the build
starting event is generated, the streamer can receive a build-finished
event while still having an event (e.g., the raw command line) blocked
on the build-starting event. So the canonical order of clearing the stream
would send a build-finished event before the build-starting event, which
can be confusing to consumers of the stream. Therefore, if have to generate
an artificial aborted build-starting event, do so first (including clearing
the events blocked on the build-starting event) and only afterwards post
the build-finished event in the stream.
Change-Id: Ib33f16f74b7bee7a963df94bbcad7a56db9f07e3
PiperOrigin-RevId: 172305114
|
|
|
|
|
|
|
|
|
|
| |
There is a conceptual difference between the (maybe unsuccessful) completion
of a top-level target and a label as the root cause for a failure (i.e., a
missing source file). Indicate that difference as such, by having a separate
message for failures associated with an unconfigured label.
Change-Id: I3f2e20d4dc85782eb11b104a7baf089e66d972e7
PiperOrigin-RevId: 172299938
|
|
|
|
|
|
|
|
|
| |
opposed to only through ctx.fragments.apple)
Progress towards #3424.
RELNOTES: None.
PiperOrigin-RevId: 172299240
|
|
|
|
|
|
| |
TESTED=added remote test
RELNOTES: Fixes #2574
PiperOrigin-RevId: 172294781
|
|
|
|
| |
PiperOrigin-RevId: 172199420
|
|
|
|
|
|
|
| |
This will make it easier to pass only error-handling functionality into support classes.
RELNOTES: None.
PiperOrigin-RevId: 172148072
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 172133468
|
|
|
|
|
|
|
|
|
|
|
| |
This simple system allows blaze developers to insert instrumentations in particular methods that they want to know:
1. How often are they called?
2. From which call sites are they called, with full call stack
The output is a pprof file that can then be analysed offline.
PiperOrigin-RevId: 172128440
|
|
|
|
|
|
|
| |
Remove an unnecessary warning and make all warnings for option conflicts print only if the option values are not equal.
RELNOTES: None.
PiperOrigin-RevId: 172124261
|
|
|
|
| |
PiperOrigin-RevId: 172115471
|
|
|
|
|
|
|
|
|
| |
RELNOTES[INC]: += on lists now mutates them. `list1 += list2` is now equivalent
to `list1.extend(list2)` and not equivalent to `list1 = list1 + list2` anymore.
Fixes #2350.
PiperOrigin-RevId: 172111899
|
|
|
|
|
|
|
| |
builder code.
RELNOTES: None
PiperOrigin-RevId: 172109520
|
|
|
|
|
|
| |
direct files into the deps attribute, only proto_library and objc_proto_library targets are allowed.
PiperOrigin-RevId: 172107133
|
|
|
|
|
|
| |
which causes the package containing the reference to be visited in rbuildfiles (which isn't the intended behaviour of rbuildfiles). Also add tests to guard against other types of inclusions.
PiperOrigin-RevId: 172106051
|
|
|
|
|
|
|
|
|
|
| |
Change ceb1013c1ca0238188e2714442fcfb2efb16bc6a added an event for
the structured command line to the BEP. Announce that event as a
child of the build-starting event so that it gets properly chained
and does not have to be chained in by a progress event.
Change-Id: I6aeb46b748a536da58a916b9c4e0b1b66bbd40b0
PiperOrigin-RevId: 172100341
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 172087232
|
|
|
|
|
|
|
| |
ConfigurationFragmentFactory instances to contents of BUILD files and to the file system.
RELNOTES: None.
PiperOrigin-RevId: 172086610
|
|
|
|
|
|
|
| |
Whether or not there was a catastrophic error is stored in the SpawnResult, so
we can just use that instead of passing in an additional boolean.
PiperOrigin-RevId: 172083752
|
|
|
|
|
|
|
| |
instead of the one computed based on xcode_config.
RELNOTES: None.
PiperOrigin-RevId: 172064337
|
|
|
|
| |
PiperOrigin-RevId: 172053593
|
|
|
|
|
|
|
|
|
|
| |
The `set` constructor used to be deprecated, but it was still possible to use
it by providing --incompatible_disallow_set_constructor=false.
RELNOTES[INC]: The flag --incompatible_disallow_set_constructor is no longer
available, the deprecated `set` constructor is not available anymore.
PiperOrigin-RevId: 171962361
|
|
|
|
| |
PiperOrigin-RevId: 171960869
|
|
|
|
|
|
|
|
|
|
|
| |
Removes the special casing of implicit requirements. Accumulating them and parsing them at the end of the parse() function was never enough to actually guarantee that the value not be replaced. I've gone through all options with implicit requirements to make sure that the expectation is checked after options parsing, so this change should be relatively safe.
Implicit requirements is still a broken concept - they don't actually expand based on the value given, so a user that is explicitly NOT setting a flag might unwittingly be setting all the requirements for that unset flag. Removing it fully requires redesigning or removing the flags that set it, though, so for now we are standardizing the behavior so that it behaves like any other expansion options, just one with a value.
Also consolidate the deprecated wrapper option behavior into the expansion work. It will soon be removed entirely, but for now it can get grouped in with the expansion logic, so that its differences are more explicit.
RELNOTES: None.
PiperOrigin-RevId: 171957502
|
|
|
|
|
|
|
| |
The transition period is over, these features have now been rolled out.
RELNOTES: --experimental_use_parallel_android_resource_processing and --experimental_android_use_nocompress_extensions_on_apk are removed. These features are fully rolled out.
PiperOrigin-RevId: 171957383
|
|
|
|
|
|
|
| |
Fixes #3874.
Change-Id: Ibbe3ea27b77426f551e2f70f082478edb2234749
PiperOrigin-RevId: 171957230
|
|
|
|
|
|
|
|
| |
RELNOTES[INC]: The flag --incompatible_descriptive_string_representations is no
longer available, old style string representations of objects are not supported
anymore.
PiperOrigin-RevId: 171952621
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I noticed a problem where if you have a workspace with basename
"server", clean will rudely delete the server's pid file and cause it
to commit suicide. This is because clean deletes the deep and non-deep
execroot, presumably temporarily as part of the deep execroot
migration. --deep_execroot has been enabled for more than a year now,
so hopefully we can safely remove this aggressive deleting. --expunge
can take care of old execroots if needed.
Change-Id: I445b0d7cedf2fb9a6a365eacc85b75428a981640
PiperOrigin-RevId: 171948100
|
|
|
|
|
|
| |
handle it properly.
PiperOrigin-RevId: 171906091
|
|
|
|
| |
PiperOrigin-RevId: 171906076
|
|
|
|
| |
PiperOrigin-RevId: 171905267
|
|
|
|
|
|
| |
informative if the number of summaries and the number of test targets don't agree. My guess is somehow we have duplicate configured targets?
PiperOrigin-RevId: 171904831
|
|
|
|
|
|
| |
the tool setup we do in tests doesn't necessarily have to be copied if we copy a workspace over.
PiperOrigin-RevId: 171864170
|
|
|
|
|
|
|
|
| |
Minor change, but the Rules AppEngine now supports Python with Google App Engine, so it's more than just Java.
Closes #3837.
PiperOrigin-RevId: 171843168
|
|
|
|
|
|
| |
CcToolchainProvider#getToolPathFragment.
PiperOrigin-RevId: 171837541
|
|
|
|
|
|
|
| |
The semantics of implicit requirements will soon change to adding the requirements in-place in the command line, so they will be slightly more likely to get overwritten. Explicitely check that the requirement is set, and warn appropriately if the user is sending mixed signals.
RELNOTES: None.
PiperOrigin-RevId: 171824297
|
|
|
|
|
|
| |
CppConfiguration#getLdExecutable to CcToolchainProvider.
PiperOrigin-RevId: 171818406
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If an absolute javabase is desired, the following set of rules can be used:
java_runtime_suite(name="suite", default=":runtime")
java_runtime(name="runtime", java_home=<path to the JDK>)
Then --javabase can be pointed to the java_runtime_suite() rule.
Alternatively, the java_runtime rule can reference a Make variable:
java_runtime(name="runtime", java_home="$(ABSOLUTE_JAVABASE)")
Then the Javabase can be specified on the command line like this:
--javabase=<your package>:suite --define=ABSOLUTE_JAVABASE=<path to the JDK>
RELNOTES[INC]: --javabase=<absolute path> and --host_javabase=<absolute path>
are not supported anymore. If you need this functionality java_runtime_suite(name="suite", default=":runtime") java_runtime(name="runtime", java_home=<path to the JDK>) is an alternative.
PiperOrigin-RevId: 171798416
|
|
|
|
|
|
|
|
| |
Addresses #3661
Closes #3770.
PiperOrigin-RevId: 171797773
|
|
|
|
|
|
|
| |
Configurable"
RELNOTES: None.
PiperOrigin-RevId: 171751391
|
|
|
|
|
|
|
|
|
| |
This requires moving the convenience constructor using RuleConfiguredTarget to be owned by RuleConfiguredTarget.
This refactoring is required by later work to allow SplitTransitionProvider to use configurable attributes. This would require packages/Attribute.java -> analysis/ConfiguredAttributeMapper.java, where in general, the 'analysis' package depends on the 'packages' package. This is the easiest way to prevent a circular dependency.
RELNOTES: None.
PiperOrigin-RevId: 171741620
|
|
|
|
|
|
| |
implementations.
PiperOrigin-RevId: 171730718
|
|
|
|
|
|
|
|
|
| |
MANDATORY_LINK_TARGET_TYPES has not been in use since d83d9bf1 was
released.
Closes #3869.
PiperOrigin-RevId: 171688095
|
|
|
|
| |
PiperOrigin-RevId: 171684595
|
|
|
|
|
|
|
| |
Previously the java rules returned some providers twice: once as regular providers and once wrapped in JavaInfo (e.g. JavaCompilationArgsProvider). This is unnecessary, inefficient and error prone. JavaInfo should be the only way of returning these providers.
RELNOTES: None.
PiperOrigin-RevId: 171663550
|
|
|
|
|
|
| |
OptionDescription is basically a hack to get the expansion data for options from outside the options parser, but it was being used at various points of invocation policy enforcement. In order to correctly track option origin, we only want to get this information once. Do it during the invocation policy expansion stage, not at enforcement, so that we track the information of the option's origin in the original invocation policy passed to the enforcer, not the expanded one.
PiperOrigin-RevId: 171661669
|
|
|
|
|
|
|
|
| |
Progress towards #3424.
RELNOTES[INC]: ctx.fragments.apple.sdk_version_for_platform is not supported anymore. The same information is accessible through the target @bazel_tools//tools/osx:current_xcode_config: point an implicit attribute to it (i.e. attr.label(default=Label("@bazel_tools//tools/osx:current_xcode_config")) then use ctx.attr._xcode_config[apple_common].XcodeVersionConfig].sdk_version_for_platform .
PiperOrigin-RevId: 171652446
|
|
|
|
|
|
|
| |
Progress towards #3424.
RELNOTES: None.
PiperOrigin-RevId: 171648540
|
|
|
|
|
|
|
| |
Rename it to TemplateExpander and start rewriting the documentation to refer
to template variables.
PiperOrigin-RevId: 171648255
|
|
|
|
|
|
|
|
| |
Progress towards #3424.
RELNOTES[INC]: ctx.fragments.apple.minimum_os_for_platform_type is not supported anymore. The same information is accessible through the target @bazel_tools//tools/osx:current_xcode_config: point an implicit attribute to it (i.e. attr.label(default=Label("@bazel_tools//tools/osx:current_xcode_config")) then use ctx.attr._xcode_config[apple_common].XcodeVersionConfig].minimum_os_for_platform_type .
PiperOrigin-RevId: 171648040
|
|
|
|
|
|
|
|
|
|
|
| |
rules only add the minimum version of the OS to the output directory name if the configuration is behind an AppleBinaryTransition, or if a minimum_os flag (such as --ios_minimum_os) is specified on the command line.
This is necessary so that the only time the minimum OS version affects the output directory name is when it's explicitly specified and therefore is accessible without looking at the xcode_config rule.
Progress towards #3424.
RELNOTES: None.
PiperOrigin-RevId: 171641295
|