| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dependencies.
This is a reland of https://github.com/bazelbuild/bazel/commit/5deca4cf88f5568771f2c836a9b8c693b88bd749.
This will make protoc see as direct dependencies the .proto files that were included using the proto_source_root flag.
Until now, Bazel passed to protoc the direct dependencies of a target as the path relative to the WORKSPACE, which made it fail when a shorter path, relative to the package was used.
Progress on #4544.
RELNOTES: None.
PiperOrigin-RevId: 203808292
|
|
|
|
|
|
|
|
|
|
| |
Sources:
https://github.com/bazelbuild/bazel-blog/commit/846478d6943162f4c4d7d50001069e0ca7b2ec28
https://github.com/bazelbuild/bazel-blog/commit/aacaa25314678c08772372b3d46697f7963bb201
RELNOTES: None.
PiperOrigin-RevId: 203763253
|
| |
|
|
|
|
| |
This reverts commit a2cac548616e6e6f433df27146c2971f352a4041.
|
| |
|
|
|
|
|
|
| |
instead of indirecting through the toolchain's compatible_javacopts.
PiperOrigin-RevId: 203502116
|
|
|
|
|
| |
RELNOTES: Remove support for java_runtime_suite; use alias() together with select() instead.
PiperOrigin-RevId: 203393253
|
|
|
|
|
|
|
| |
Before this cl the sysroot variable was not present, and that's a bug.
RELNOTES: None
PiperOrigin-RevId: 203346557
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use try-with-resources to ensure OutputStreams
that we open via FileSystem.OutputStream(path)
are closed.
Eagerly closing OutputStreams avoids hanging on to
file handles until the garbage collector finalizes
the OutputStream, meaning Bazel on Windows (and
other processes) can delete or mutate these files.
Hopefully this avoids intermittent file deletion
errors that sometimes occur on Windows.
See https://github.com/bazelbuild/bazel/issues/5512
RELNOTES: none
PiperOrigin-RevId: 203342889
|
|
|
|
|
|
|
| |
https://github.com/bazelbuild/bazel/commit/732dc512801c32207c252a76ca8d9e5544560339.
RELNOTES: Allow @ in package names.
PiperOrigin-RevId: 203270369
|
|
|
|
| |
PiperOrigin-RevId: 203230801
|
|
|
|
|
|
|
|
| |
producing add_dep commands where possible and avoids the need for direct dependencies on supertypes of directly depended types
RELNOTES: None.
PiperOrigin-RevId: 203164113
|
|
|
|
|
|
|
|
|
|
| |
Add a new standard feature set to the Xcode version being used for
compilation. (The feature is named `xcode_VERSION`, where `VERSION` is
at least a two-component version number; `xcode_9.0` and `xcode_9.2` are
both possible values.) This provides CROSSTOOL authors a mechanism to
deploy compiler flags supported only in certain Xcode versions.
PiperOrigin-RevId: 203000420
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 202943806
|
|
|
|
| |
PiperOrigin-RevId: 202704472
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[Rolling forward https://github.com/bazelbuild/bazel/commit/c4e128e2c6d8cacaeba034d6a3195796d50f1745]
java_common.compile doesn't generate the output source jar when a source jar is
the only input for the compilation. This is wrong because the source jar can
include APT generated sources. It is also inconsistent with java_library and
leads to inconsistent Skylark rules where a declared output will not always have a
generating action.
This new behavior is guarded by a new flag --incompatible_generate_javacommon_source_jar.
RELNOTES: None.
PiperOrigin-RevId: 202648346
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an implementation of the design at
https://docs.google.com/document/d/1g91BWJITcYw_X-VxsDC0VgUn5E9g0kRBGoBSpoO41gA/edit>.
More thorough documentation will be sent in a separate cl. The api was approved
at
https://docs.google.com/document/d/1M8JA7kzZnWpLZ3WEX9rp6k2u_nlwE8smsHYgVTSSJ9k/edit?ts=5b292400#.
Work towards #4571 (only the docs are missing).
RELNOTES: None.
PiperOrigin-RevId: 202464331
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 202360925
|
|
|
|
|
|
|
|
|
| |
Consolidate the creation of JavaCompilationArgsProviders, and avoid explicit
handling of the 'direct' and 'recursive' cases in clients. Also add some
higher-level methods to the builder API to support adding dependencies
with dep/export/runtime_dep-like semantics.
PiperOrigin-RevId: 202166383
|
|
|
|
|
|
|
| |
This was never used. We thought it will be useful, but it's not.
RELNOTES: None.
PiperOrigin-RevId: 202143524
|
|
|
|
|
| |
Change-Id: I355b138e143771fd826ab03951df821ea7d58ac5
PiperOrigin-RevId: 201740564
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
see b/109887056
*** Original change description ***
Stop objc_proto_library from returning the generated sources.
PiperOrigin-RevId: 201709908
|
|
|
|
|
|
|
|
| |
RELNOTES: None
*** Reason for rollback ***
PiperOrigin-RevId: 201686843
|
|
|
|
|
|
|
|
|
| |
CrosstoolInfo carries the necessary information from the CROSSTOOL text proto. Later on, instead from the CROSSTOOL file and the corresponding CToolchain, CrosstoolInfo will be derived from a skylark_crosstool rule implemented in Skylark. Therefore CToolchain involvement in CppConfiguration and CcToolchain creation needs to be eliminated.
Work towards issue #5380
RELNOTES: None.
PiperOrigin-RevId: 201491207
|
|
|
|
|
|
| |
RELNOTES[NEW]: Allow @ in package names.
PiperOrigin-RevId: 201487916
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
RELNOTES=None
PiperOrigin-RevId: 201365986
|
|
|
|
|
|
|
| |
I will put cc_import.bzl in Bazel in a follow up CL.
RELNOTES:none
PiperOrigin-RevId: 201332133
|
|
|
|
|
| |
RELNOTES: Support for LIPO has been fully removed.
PiperOrigin-RevId: 200724578
|
|
|
|
|
|
| |
*** Reason for rollback ***
PiperOrigin-RevId: 200605975
|
|
|
|
|
|
| |
callables that depend on CToolchain in CppConfiguration.
PiperOrigin-RevId: 200559893
|
|
|
|
|
|
|
|
|
|
|
| |
Make all external repositories depend on an additional SkyValue controllable
via commands, so support unconditional fetching of all external repositories,
as it is needed by the the `sync` command.
Improves on #5175, provides a work around for #4907.
Change-Id: I30033614c1a2fad3f1363b85ff69cf92f697c255
PiperOrigin-RevId: 200543985
|
|
|
|
|
|
|
|
|
|
| |
To disambiguate:
- @foo refers to the external dependency @foo//:foo (as before this change).
- //@foo refers to the target //@foo:@foo (i.e. in the default workspace).
RELNOTES[NEW]: Allow @ in package names.
PiperOrigin-RevId: 200541716
|
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 200471197
|
|
|
|
|
|
|
|
| |
and output groups.
* Make ctx a keyword argument so that we can more easily add more parameters in the future and eventually remove ctx.
PiperOrigin-RevId: 200453550
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the selection of C++ toolchain configuration depends on 2 different things:
1. CROSSTOOL file: a proto text file that contains multiple CrosstoolConfig.CToolchain messages, out of which we want to select the appropriate CToolchain;
2. cc_toolchain_suite rule, specified by --crosstool_top option: this rule contains "toolchains" map attribute. The map's keys are of type <cpu>|<compiler>, or just <cpu>, and the values are labels of cc_toolchain rules (which contain additional C++ information).
If there is an entry in cc_toolchain_suite.toolchains that corresponds to the --cpu and --compiler options, we use it, otherwise we loop through all the CToolchains in the CROSSTOOL file, select the one that corresponds to the --cpu and --compiler options, and then get the cc_toolchain label from cc_toolchain_suite.toolchains[toolchain.targetCpu|toolchain.compiler].
In both cases we read the CROSSTOOL file and pass all its information forward, to be used in creation of CppConfiguration and CcToolchainProvider creation.
As part of the efforts of rewriting CROSSTOOL in Skylark, we need to make obtaining the cc_toolchain label independent of the CROSSTOOL file and toolchain selection. As a step towards that goal, we add a new "toolchain_identifier" attribute to cc_toolchain, which uniquely identifies a CToolchain in the CROSSTOOL file.
Now the process of getting the CToolchain goes as follows:
Check for existence of cc_toolchain_suite.toolchains[<cpu>|<compiler>], if --compiler is specified, otherwise check for cc_toolchain_suite.toolchains[<cpu>].
1. if a value is found, load the cc_toolchain rule and look for the toolchain_identifier attribute.
1.a if the attribute exists, loop through all the CToolchains in CROSSTOOL and select the one with the matching toolchain identifier.
1.b otherwise fall back to selecting the CToolchain from CROSSTOOL by matching the --cpu and --compiler values.
2. If a value is not found, select the CToolchain from CROSSTOOL by matching the --cpu and --compiler values, and construct the key as follows: <toolchain.cpu>|<toolchain.compiler>.
In the future we will get rid of 2. by making sure that cc_toolchain_suite.toolchains[<cpu>|<compiler>] and cc_toolchain_suite.toolchains[<cpu>] are always defined.
1.b will be removed by making the cc_toolchain.toolchain_identifier attribute mandatory
After this deriving the cc_toolchain label will be independent of the CROSSTOOL file
1.a will ultimately be replaced by an attribute that points to a skylark_crosstool rule, that will contain all the information that CROSSTOOL contains, allowing us to remove CROSSTOOL altogether.
Work towards issue #5380
RELNOTES: None.
PiperOrigin-RevId: 200388550
|
|
|
|
|
|
|
|
|
|
| |
PathFragments are not well supported in Skylark, quite the opposite, the Skylark
team tries hard to not use path fragments if possible. All existing users I
looked into had to convert the PathFragment to string using str() anyway.
Because of that this cl should not break anybody.
RELNOTES: None.
PiperOrigin-RevId: 200372447
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 200366616
|
|
|
|
|
|
|
|
| |
--experimental_android_local_test_binary_resources to true.
RELNOTES[NEW]: android_local_test now takes advantage of Robolectric's binary resource processing which allows for faster tests.
PiperOrigin-RevId: 200296572
|
|
|
|
| |
PiperOrigin-RevId: 199864175
|
|
|
|
|
|
|
|
| |
Derived artifacts' owners are important because they are used to determine the artifact's generating action. Source artifacts' owners are not used in this way, so I left them alone.
This allows us to get rid of most uses of ArtifactSkyKey. We may be able to delete it entirely in a follow-up.
PiperOrigin-RevId: 199836436
|
|
|
|
|
|
|
|
|
|
| |
try)
This is a roll forward of https://github.com/bazelbuild/bazel/commit/3ab52e63079f1e43cb2c973425f615836a334082. The issue caused the objc rule breakage was fixed by https://github.com/bazelbuild/bazel/commit/5176300577b53a15128b3cb6a17d7883c5b7090e.
RELNOTES:
Flip default value of --experimental_shortened_obj_file_path to true, Bazel now generates short object file path by default.
PiperOrigin-RevId: 199806300
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Suspected root cause behind tons of Blaze nightly failures.
One example:
[]
*** Original change description ***
Let blaze obfuscate manual main_dex_list according to proguard map.
PiperOrigin-RevId: 199737371
|
|
|
|
| |
PiperOrigin-RevId: 199627983
|
|
|
|
|
|
|
| |
LSC is finished.
RELNOTES:none
PiperOrigin-RevId: 199619978
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This cl adds Skylark constants allowing users to specify which C++ action they
want for the feature configuration Skylark API. This is done by exposing a
Skylark file at @bazel_tools//tools/cpp:action_names.bzl.
Skylark api to the C++ toolchain doc:
https://docs.google.com/document/d/1g91BWJITcYw_X-VxsDC0VgUn5E9g0kRBGoBSpoO41gA/edit#.
Progress on #4571.
RELNOTES: None.
PiperOrigin-RevId: 199596778
|
|
|
|
|
|
| |
(minor) ActionFS now implements MetadataProvider.getInput
PiperOrigin-RevId: 199575194
|
|
|
|
| |
PiperOrigin-RevId: 199529974
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 199382344
|
|
|
|
|
|
|
| |
Crosstool selection will be based solely on --cpu and --compiler options.
RELNOTES: Option --glibc is removed, toolchain selection relies solely on --cpu and --compiler options.
PiperOrigin-RevId: 199156131
|