| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This corresponds to the os version in the clang target triple, though clang
does have corresponding os_version_min flags for Apple platforms.
Currently, Bazel has --XX_minimum_os flags for XX values corresponding to Apple
platforms.
This flag is the generic version of that (and can and will be set after the
Apple split transition, and will eventually be set in the Android split as
well) to support various Android API level improvements for native code.
PiperOrigin-RevId: 201453961
|
|
|
|
|
|
|
|
| |
https://github.com/bazelbuild/bazel/commit/2a9e125499c8fadb731420a1a9dfe7adc8f08792
Bazel now supports @bazel_tools//tools/jdk:current_host_java_runtime.
PiperOrigin-RevId: 201441513
|
|
|
|
|
|
|
| |
tests.
RELNOTES: None.
PiperOrigin-RevId: 201432990
|
|
|
|
|
|
|
|
|
|
| |
Label.parseAbsoluteUnchecked. Label already interns all labels, so the additional interning being done in every ConfiguredRuleClass.Builder was pointless memory and CPU.
Keeping the RuleDefinitionEnvironment around makes things harder to serialize.
Done using IntelliJ structural replace and then a super-painful adding of imports to every file that didn't compile (have to learn a better way to do this).
PiperOrigin-RevId: 201427027
|
|
|
|
|
|
|
|
|
|
|
| |
The master bazelrc is now defined by preprocessor macro at (Bazel's) compile time. The default is still /etc/bazel.bazelrc for most platforms, but windows now has a %ProgramData% relative default value as well. Users wishing to change this default when building Bazel for a new platform should edit BAZEL_SYSTEM_BAZELRC_PATH in src/main/cpp/BUILD.
Part of https://github.com/bazelbuild/bazel/issues/4502, relevant to the duplicate issue #4809.
TESTED: default settings were tested manually, since they cannot be tested in a sandbox
RELNOTES: Windows default system bazelrc is read from the user's ProgramData if present.
PiperOrigin-RevId: 201423446
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The corresponding flags have been flipped and there should be no code in the depot that violates these rules.
* Make it completely illegal for proto_library to appear in any Java/Android rule
* Delete code that uses the old migration flags.
* Delete tests that check that Java/Android rules *can* depend on proto_library rules when certain flags are off.
* Update tests (the error messages are now slightly different)
RELNOTES: None
PiperOrigin-RevId: 201384236
|
|
|
|
|
|
|
| |
It looks like this test was intended to add coverage for these option-like values that we accept as commands, but it did not actually test this.
RELNOTES: None.
PiperOrigin-RevId: 201380534
|
|
|
|
|
|
|
|
|
|
| |
useEnvironment
Unfortunately this doesn't work for all callers, namely NativeInfo objects, as they may have structField callables invoked from contexts that have no environment available.
RELNOTES[INC]: Skylark structs (using struct()) may no longer have to_json and to_proto overridden.
PiperOrigin-RevId: 201376969
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 201367075
|
|
|
|
|
| |
RELNOTES=None
PiperOrigin-RevId: 201365986
|
|
|
|
|
|
| |
The general handling should be fine for this.
PiperOrigin-RevId: 201352916
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now we have:
bool AsAbsoluteWindowsPath(const std::wstring& path, std::wstring* result, std::string* error);
This change helps making the C++ native launcher work with UTF-16.
See https://github.com/bazelbuild/bazel/issues/4473
Closes #5406.
Change-Id: I7eaf55f9fe5a4d41e3dd09edc2a21e9b3cc9277c
PiperOrigin-RevId: 201352866
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix breakage introduced in #5385 due to incorrect use of `std::move` on local temporary variable after function returns (found by Clang on Windows).
Since `OneYearDelay` function will return the same value and `kOneYear` is only used in one place, remove unused `OneYearDelay` function and move `kOneYear` to `GetFuture` as a `constexpr` constant.
Drive-by improvement: remove some const reference in function signatures. `FILETIME` is a plain C struct with size of 64-bit, so it is trivially-copyable and can easily fit into a 64-bit register. It is more efficient to pass `FILETIME` by value (smaller code size).
/cc @laszlocsomor
Closes #5434.
Change-Id: I136fe4a8ce1b274a80e3206b62e6087dd0f8f5eb
PiperOrigin-RevId: 201343053
|
|
|
|
|
|
|
|
| |
Based on work of Sun Zhiyi <zhiyisun@gmail.com>.
Closes #5360.
PiperOrigin-RevId: 201339882
|
|
|
|
|
|
|
|
|
|
| |
This gives us more coverage for command startup, especially wrt. modules. We
have some modules that are known to be slow, and this immediately shows any
such issues. I've already tracked down two issues with this change, and it
would also have shown a recently fixed regression.
RELNOTES: None.
PiperOrigin-RevId: 201337059
|
|
|
|
|
|
|
| |
I will put cc_import.bzl in Bazel in a follow up CL.
RELNOTES:none
PiperOrigin-RevId: 201332133
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a regression test for the size of the Bazel
binary, by asserting the number of embedded tools.
Sudden, unexpectedly large changes in the number
of embedded tools can be indicative of an
unintentional addition/removal of embedded tools
and unexpected growth/shrinkage of the Bazel
binary.
Fixes https://github.com/bazelbuild/bazel/issues/5378
Change-Id: I7880f4544c560eb627ef5fb8a55ff1b377ec156b
Closes #5399.
Change-Id: I10c8cdcd5e675cbc0bac43003741a8af27248992
PiperOrigin-RevId: 201318396
|
|
|
|
|
|
| |
RELNOTES[INC]: The $(JAVA_TRANSLATIONS) Make variable is not supported anymore.
PiperOrigin-RevId: 201278971
|
|
|
|
|
|
|
| |
statistics tests, and increase granularity of the waits.
RELNOTES: None.
PiperOrigin-RevId: 201254824
|
|
|
|
|
|
|
| |
To start we add just a single metric, the number of actions constructed in the current build.
RELNOTES: None
PiperOrigin-RevId: 201248490
|
|
|
|
|
|
| |
Reviewed at: https://github.com/bazelbuild/bazel/pull/5425
PiperOrigin-RevId: 201241451
|
|
|
|
|
|
|
| |
ExecutionPlatformConstraintsAllowed set to PER_TARGET and also have an
alread-existing exec_compatible_with attribute.
PiperOrigin-RevId: 201238805
|
|
|
|
|
|
|
|
| |
LinkedHashMultimap as well. Let ImmutableSetRuntimeCodec handle some other sets. We squash these extra types into the same codec because we want them to become immutable anyway, and they can be dealt with easily by the existing codecs.
Add some more non-Bazel classes that should be DynamicCodec'ed. Also, when a disallowed value is serialized, throw a SerializationException instead of crashing. This makes it easier to recover in tests.
PiperOrigin-RevId: 201237631
|
|
|
|
| |
PiperOrigin-RevId: 201228699
|
|
|
|
|
|
|
|
|
| |
When set, any action parameter files are written locally upon action execution, even when the action is executed remotely. This is mainly useful for debugging.
This option is effectively implied by --subcommands and --verbose_failures, as it is likely that the user is debugging actions when using these flags.
RELNOTES: Add --materialize_param_files flag to write parameter files even when actions are executed remotely.
PiperOrigin-RevId: 201225566
|
|
|
|
|
|
| |
but the "exec_compatible_with" attribute is present.
PiperOrigin-RevId: 201219412
|
|
|
|
|
|
| |
default.
PiperOrigin-RevId: 201218341
|
|
|
|
|
|
|
|
|
|
| |
Turns out the event handler (BlazeCommandEventHandler) prints almost all
event types, and I don't believe there's a way to tune it.
We certainly don't want these messages printed to the console unless
we're debugging the debugger, so turn them off by default.
PiperOrigin-RevId: 201211355
|
|
|
|
|
|
| |
and have DynamicCodec add to it. It's very useful to have this trail available when debugging or whitelisting.
PiperOrigin-RevId: 201205884
|
|
|
|
| |
PiperOrigin-RevId: 201205388
|
|
|
|
| |
PiperOrigin-RevId: 201203706
|
|
|
|
|
|
| |
Get rid of a useless tag, because the Function being tagged is a concrete class, so won't be serializable. Will deal with it in a follow-up. Implement equality for BazelInfo.
PiperOrigin-RevId: 201199255
|
|
|
|
|
|
|
| |
checked for restricted_to and compatible_with constraints, because they are part
of the execution, not providing new dependencies.
PiperOrigin-RevId: 201196891
|
|
|
|
|
|
| |
lambdas as Serializable.
PiperOrigin-RevId: 201191461
|
|
|
|
|
|
| |
expect equality, not because there's no implementation.
PiperOrigin-RevId: 201191262
|
|
|
|
|
|
|
|
|
|
|
| |
For paths passed to Bazel on the command line, the shell expands these variables, but for hardcoded defaults, we must make the library call ourselves.
We do not add similar support in Posix systems, where it is less common to rely on standard path-related variables.
Prerequisit for issue #4502.
RELNOTES: None.
PiperOrigin-RevId: 201183214
|
|
|
|
|
|
|
|
|
| |
Rolls forward https://github.com/bazelbuild/bazel/commit/c720152ec1936a537c9519d522d3cb41d19cff77.
This CL includes testing to make sure that linker parameters coming from every possible provider in Python rules is propagated.
RELNOTES:none
PiperOrigin-RevId: 201160720
|
|
|
|
|
|
|
|
|
|
|
| |
CcToolchainFeatures.ActionConfig that are needed for FeatureConfiguration creation
In the future CcToolchainFeatures will not be created from a CToolchain but from a CrosstoolInfo provider that will encapsule all relevant information from the CROSSTOOL. Feature and ActionConfig classes need to carry all the information that is currently obtained from CToolchain.
Work towards issue #5380
RELNOTES: None.
PiperOrigin-RevId: 201147336
|
|
|
|
| |
PiperOrigin-RevId: 201144030
|
|
|
|
|
|
|
|
| |
as this isn't supported by `((... == 0))` below.
See bazelbuild/bazel#5413
PiperOrigin-RevId: 201135798
|
|
|
|
|
|
|
|
| |
ActionConflictException. We can construct the exception message eagerly, since it is going to be thrown with very high likelihood in any case.
The complex objects inside it made it hard to serialize.
PiperOrigin-RevId: 201130522
|
|
|
|
|
|
|
| |
The memory savings from this flag are not worth the complexity, and it interferes with action restarting.
RELNOTES: Remove support for --discard_actions_after_execution.
PiperOrigin-RevId: 201077905
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
See linked bug.
*** Original change description ***
C++: Refactors PyWrapCc to make it easier to migrate to Skylark
Rolling forward https://github.com/bazelbuild/bazel/commit/6c87715b8ac6b32e636ba307440e2b7362b10a48. When I first tried to roll forward this CL I missed one place where PyCcLinkParamsProvider.TO_LINK_PARAMS should have been called.
The target //production/midas/config:client_config_pb builds fine now.
RELNOTES:none
PiperOrigin-RevId: 201070354
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ConfiguredRuleClassProvider can specify a predicate which accepts an
OptionsDiff and the new BuildOptions in order to make a decision on whether
the given diff requires the analysis cache to be dropped.
This predicate is only called if all of the following hold:
* there was an old configuration collection (if not, the cache is not
dropped because there wasn't one yet)
* the old configuration collection is not exactly equal to the new
configuration collection (if it is, the cache is not dropped because
it definitely hasn't changed)
* the old configuration collection has the same number of configurations
as the new collection (if not, the cache is always dropped because
experimental_multi_cpu has changed, definitely not a flag which should
cause old analysis cache to stick around!)
If all of these hold, the old target configurations are paired up with
the new target configurations by index in the configuration collection,
and each pair is diffed. The predicate is called with each diff and the
corresponding new configuration's build options. If any of these
invocations returns true, the cache is dropped. Otherwise, the cache is
kept for the next build.
No implementation of this predicate is actually supplied for this
change, so the old behavior (always drop the cache if the configuration
changes at all) holds.
RELNOTES: None.
PiperOrigin-RevId: 201050049
|
|
|
|
|
|
|
|
|
| |
Change-Id: I3655868d34dd98f5cde084a61995dfae8e4b94c0
Closes #5374.
Change-Id: I3655868d34dd98f5cde084a61995dfae8e4b94c0
PiperOrigin-RevId: 201032126
|
|
|
|
|
|
| |
Closes #5403.
PiperOrigin-RevId: 201007405
|
|
|
|
|
|
|
|
|
|
|
|
| |
This functionality will be useful for node restarting. More than one
parent node may request the restart of a shared child node, and this
should not fail.
Instead, the returned MarkedDirtyResult indicates whether the dirtying
was redundant, and the calling code can assert on that.
RELNOTES: None.
PiperOrigin-RevId: 201005663
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a flag to the installer to skip uncompressing the base image during installation.
Uncompressing the base image during installation can be problematic:
1. If you configure the startup option `output_user_root` you'll wind up extracting the image twice. Once during installation and a second time during the first bazel invocation in your project.
2. If you're bootstrapping Bazel in a controlled environment (in my case via Nix) then you can get permission errors if Bazel defaults to extracting to the home directory. There's no way to skip this extraction and for the time being I have resorted to seting `HOME` to a throw away directory during install.
Closes #5303.
PiperOrigin-RevId: 201004235
|
|
|
|
|
|
| |
of ConfiguredTarget implements equality, it's very much not comparable.
PiperOrigin-RevId: 201004116
|