| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
| |
compiled as part of bazel's repository bootstrap. This should make crosstool's clang invocations faster. An added benefit of this is that wrapped_clang.cc supports the "DSYM_HINT" flags specified through the CROSSTOOL, so with this change, apple_binary gets support for the --apple_generate_dsym flag.
The dSYM generation issue has been flagged multiple times:
https://github.com/bazelbuild/bazel/issues/4312
https://github.com/bazelbuild/bazel/issues/3940
https://github.com/bazelbuild/bazel/issues/3372
RELNOTES: apple_binary can now generate dSYM outputs with the --apple_generate_dsym=true flag.
PiperOrigin-RevId: 184688215
|
|
|
|
|
|
|
| |
Fix the create_main_dex_list stub script to find the dx jar binary correctly.
RELNOTES: None
PiperOrigin-RevId: 184532530
|
|
|
|
|
|
|
|
| |
This is a rather small change to a Python tool used to produce a SHA256 hash. Currently, the whole file is loaded in memory before computing the hash, which causes problem when large files are processed. For instance, github.com/bazelbuild/rules_docker uses it to compute the hash of Docker images, which can be multiple GB in size. This PR avoids the tool to cause issues in a limited-memory environment.
Closes #4243.
PiperOrigin-RevId: 184518900
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also update the Python stub script template to set
$RUNFILES_MANIFEST_FILE or $RUNFILES_DIR so the
runfiles library only needs to look for those.
See https://github.com/bazelbuild/bazel/issues/4460
RELNOTES[NEW]: python,runfiles: You can now depend on `@bazel_tools//tools/runfiles:py-runfiles` to get a platform-independent runfiles library for Python. See DocString of https://github.com/bazelbuild/bazel/blob/master/src/tools/runfiles/runfiles.py for usage information.
Change-Id: I4f68a11cb59f2782e5203e39fe60cc66b46023a2
PiperOrigin-RevId: 184515490
|
|
|
|
|
|
|
|
|
| |
..by the `build_file` parameter, even if the external repository contains a
top-level BUILD file. While there, also add a test verifying that this is
also possible via the `build_file_content`.
Change-Id: I1b875c147cfcd6f1c70b8efeb10c2b406eeacf6a
PiperOrigin-RevId: 184134041
|
|
|
|
|
|
|
|
| |
http_archive from @bazel_tools does know how to bring its own
BUILD file by now.
Change-Id: I9bbda6635f4459b77600e9ee6db3284f826d7931
PiperOrigin-RevId: 184129975
|
|
|
|
|
|
|
| |
Fixes #4537.
Change-Id: I28afcbc89e230e319788c2426e57d43c1ad5dfee
PiperOrigin-RevId: 183827742
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add logging to bazel_bootstrap_distfile_test in
case it is running on Windows. The logging will
help collect basic performance stats.
Also remove the %N placeholder from `date` format
string in the log messages, because macOS doesn't
support it.
See https://github.com/bazelbuild/bazel/issues/4503
Change-Id: Idf00bf1512d02a793b27e1cc761fbcd630e79618
PiperOrigin-RevId: 183642578
|
|
|
|
|
|
|
|
|
|
|
| |
Use BytesIO instead of StringIO, change strings to bytes throughout the
archiving code. Needed to import from Six in a couple of places.
As discussed in #1580
Closes #3850.
PiperOrigin-RevId: 183429066
|
|
|
|
|
| |
RELNOTES: Replace //tools/defaults:android_jar with @bazel_tools//tools/android:android_jar. //tools/defaults:android_jar will be removed in a future release.
PiperOrigin-RevId: 183404151
|
|
|
|
|
|
|
| |
It is optional as of https://github.com/bazelbuild/bazel/commit/1a6ca6f47aef36d56b5cb2f9da114af75dde583d.
RELNOTES: None
PiperOrigin-RevId: 183391869
|
|
|
|
|
|
|
| |
We don't use it.
RELNOTES: None
PiperOrigin-RevId: 183275864
|
|
|
|
|
|
|
|
|
|
| |
Move the print statement about the used BUILD file earlier in the
_http_archive_impl function, so that the BUILD file is accessed
before we call out to the network for the first time. In this way,
we avoid fetching the same file twice in a single build.
Change-Id: I2b9be4e6a00da2de0cde56896d84c0ba9721456d
PiperOrigin-RevId: 183251555
|
|
|
|
|
|
|
|
|
| |
if not.
Fixes #4065.
Change-Id: I17a5d2ee4befc5e467b0a195311566db246eb167
PiperOrigin-RevId: 183087906
|
|
|
|
|
|
| |
Fixes #4513
PiperOrigin-RevId: 183060664
|
|
|
|
|
|
|
|
| |
android_instrumentation_test's runfiles.
GITHUB: #903
RELNOTES: None.
PiperOrigin-RevId: 182940009
|
|
|
|
|
|
|
| |
access.
Change-Id: I6041c51823fa52d6ae55dfe06afd1754ce05ab98
PiperOrigin-RevId: 182904580
|
|
|
|
|
|
|
|
|
|
| |
Bazel may also depend on external repositories that already contain
build files. When using http_archive from @bazel_tools also support
that use case, by supporting simply omitting `build_file` and
`build_file_contents`.
Change-Id: I40a9b85ae0aba850c73104d2e2fe7f7ee814e093
PiperOrigin-RevId: 182893460
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks C++ on gcc 4.8.4 (specifically, TensorFlow: https://github.com/bazelbuild/bazel/issues/4474)
Fixes #4474
*** Original change description ***
When linking mostly-static Linux binaries, link libstdc++.a explicitly.
This allows libstdc++ to be statically linked, which is normally only
possible when invoking GCC as `g++` with the `-static-libstdc++` flag.
Fixes https://github.com/bazelbuild/bazel/issues/2840
See https://github.com/envoyproxy/envoy/issues/415 for additional
background and context.
cc @htuch (for Envoy) and @calpeyser @hlopko (who I talked to earlier about this)...
***
RELNOTES: None.
PiperOrigin-RevId: 182519445
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 182416060
|
|
|
|
|
|
|
|
| |
deploy jar at @android_test_support//:instrumentation_test_runner alias to @android_test_support//opensource:entry_point_deploy.jar
GITHUB: #903
RELNOTES: None.
PiperOrigin-RevId: 182310718
|
|
|
|
|
|
|
|
|
| |
Fixes https://github.com/bazelbuild/bazel/issues/4439.
Empty assets are handled by writing out an empty file named "assets/empty_asset_generated_by_bazel~", which will silently be ignored by AAPT.
RELNOTES: aar_import now supports assets.
PiperOrigin-RevId: 182110400
|
|
|
|
|
|
|
|
| |
Issue #4401
Closes #4437.
PiperOrigin-RevId: 182067976
|
|
|
|
|
|
|
|
|
|
|
| |
Support applying a sequence of commands to an http_archive,
after the patch files are applied. In this way, tasks like
shebang-fixes can easily be added.
Fixes #3395.
Change-Id: Ifdad584a852efd425c436d57ef71a0d681488629
PiperOrigin-RevId: 182037265
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also make most targets in `//src/tools/runfiles`
private. The user should depend on
`@bazel_tools//tools/runfiles:$LANG-runfiles`
instead.
See https://github.com/bazelbuild/bazel/issues/4460
RELNOTES[NEW]: java,runfiles: You can now depend on `@bazel_tools//tools/runfiles:java-runfiles` to get a platform-independent runfiles library for Java. See JavaDoc of https://github.com/bazelbuild/bazel/blob/master/src/tools/runfiles/java/com/google/devtools/build/runfiles/Runfiles.java for usage information.
Change-Id: Iba9113453222ae74ce42a324272711f613104891
PiperOrigin-RevId: 182022851
|
|
|
|
|
|
|
|
|
|
|
| |
Support applying a sequence of patches for external repositories
imported via http_archive. (Note that we only support the version
from @bazel_tools, not the deprecated native rules.)
Works towards #3395.
Change-Id: I96c746acc04790b051eb686856c04a3ff3c90059
PiperOrigin-RevId: 181975322
|
|
|
|
|
|
|
| |
Fixes #3699.
Change-Id: I44028476be96037334a1ae48de450d625925676f
PiperOrigin-RevId: 181962926
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1.Deleted config_setting for --cpu=x64_windows_msys, because we don't build
Bazel with MSYS gcc anymore.
2.Deleted config_setting for --cpu=x64_windows_msvc, because it uses exactly
the same toolchain as --cpu=x64_windows, it'll be removed in the future.
This change reduces the complexity of our BUILD files and make them less
confusing.
Change-Id: I939831a6861413b0f745fb1be98aacd4fb780e0a
PiperOrigin-RevId: 181751853
|
|
|
|
|
| |
Change-Id: I61def9d449a8b05dde4f96983b84488a71be63a4
PiperOrigin-RevId: 181742031
|
|
|
|
|
|
|
|
|
|
|
|
| |
Continuation of https://github.com/bazelbuild/bazel/pull/4356
An approach at supporting strip_prefix with the git skylark rules.
This approach unfortunately uses symlinks since you cannot clone a subset of a git repository. It creates a tmp directory which is the 'real' clone and then provides a link in place of the expected location of the repository to the path of the required prefix. Behaviour is only changed if a strip_prefix is provided.
Closes #4368.
PiperOrigin-RevId: 181438640
|
|
|
|
|
|
|
|
| |
Fixes https://github.com/bazelbuild/bazel/issues/4359
Closes #4360.
PiperOrigin-RevId: 181161619
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`_clone_or_update()` should `git clone` external repositories only if repo is absent. Unfortunately, it may happen that the bazel outputRoot (~/.cache/bazel by default) is a subdirectory of some other git working copy. For example, user may track his whole home directory in git and add `.config` to .gitignore. In that case, it is not enough to check if the cache dir is a git repo. One must check that the cache dir holds a root of a git working copy. In other words, the `.git` folder must be in the repo dir, not on any level above.
* Steps to reproduce
```bash
cd ~/.cache
git init
cd /some/project/that/uses/bazel-git_repository
mv WORKSPACE WORKSPACE.orig
(echo "load('@bazel_tools//tools/build_defs/repo:git.bzl', 'git_repository')" ; cat WORKSPACE.orig) > WORKSPACE
bazel --batch build :all || echo "Ah, there is a bug"
```
Read on for definitive info.
* clone any project that uses `git_repository`
```bash
[arch@archlinux bazelbuild]$ git clone https://github.com/bazelbuild/bazel-watcher.git
[arch@archlinux bazelbuild]$ cd bazel-watcher
```
* enable Skylark implementation of `git_repository` as documented in https://github.com/bazelbuild/bazel/issues/1408#issuecomment-276815467
```bash
[arch@archlinux bazel-watcher]$ mv WORKSPACE WORKSPACE.orig
[arch@archlinux bazel-watcher]$ (echo "load('@bazel_tools//tools/build_defs/repo:git.bzl', 'git_repository')" ; cat WORKSPACE.orig) > WORKSPACE
[arch@archlinux bazel-watcher]$ grep -v ^# WORKSPACE |head -n4
load('@bazel_tools//tools/build_defs/repo:git.bzl', 'git_repository')
git_repository(
name = "com_github_bazelbuild_bazel_integration_testing",
```
* (optionally) define custom Bazel `outputRoot` directory (default is ~/.cache/bazel)
```bash
[arch@archlinux bazel-watcher]$ rm -rf /tmp/.cache/ ; mkdir /tmp/.cache/
[arch@archlinux bazel-watcher]$ export TEST_TMPDIR=/tmp/.cache/bazel
```
* try building the project to make sure everything works as expected
```bash
[arch@archlinux bazel-watcher]$ bazel --batch build :all
INFO: $TEST_TMPDIR defined: output root default is '/tmp/.cache/bazel' and max_idle_secs default is '15'.
Extracting Bazel installation...
WARNING: /tmp/.cache/bazel/_bazel_arch/f2207b308c89ea5d32323052637210b1/external/com_github_bazelbuild_bazel_integration_testing/WORKSPACE:1: Workspace name in /tmp/.cache/bazel/_bazel_arch/f2207b308c89ea5d32323052637210b1/external/com_github_bazelbuild_bazel_integration_testing/WORKSPACE (@build_bazel_integration_testing) does not match the name given in the repository's definition (@com_github_bazelbuild_bazel_integration_testing); this will cause a build error in future versions
INFO: Analysed target //:go_prefix (6 packages loaded).
INFO: Found 1 target...
Target //:go_prefix up-to-date (nothing to build)
INFO: Elapsed time: 15.088s, Critical Path: 0.05s
INFO: Build completed successfully, 1 total action
[arch@archlinux bazel-watcher]$ echo $?
0
```
* reproduce the issue by placing the `outputRoot` under a git working copy
```bash
[arch@archlinux bazel-watcher]$ rm -rf /tmp/.cache/ ; mkdir /tmp/.cache/
[arch@archlinux bazel-watcher]$ cd /tmp/.cache/ ; git init
Initialized empty Git repository in /tmp/.cache/.git/
[arch@archlinux .cache]$ cd -
[arch@archlinux bazel-watcher]$ bazel --batch build :all
INFO: $TEST_TMPDIR defined: output root default is '/tmp/.cache/bazel' and max_idle_secs default is '15'.
Extracting Bazel installation...
ERROR: error loading package '': Encountered error while reading extension file 'tools/repositories.bzl': no such package '@com_github_bazelbuild_bazel_integration_testing//tools': Traceback (most recent call last):
File "/tmp/.cache/bazel/_bazel_arch/f2207b308c89ea5d32323052637210b1/external/bazel_tools/tools/build_defs/repo/git.bzl", line 69
_clone_or_update(ctx)
File "/tmp/.cache/bazel/_bazel_arch/f2207b308c89ea5d32323052637210b1/external/bazel_tools/tools/build_defs/repo/git.bzl", line 44, in _clone_or_update
fail(("error cloning %s:\n%s" % (ctx....)))
error cloning com_github_bazelbuild_bazel_integration_testing:
+ cd /tmp/.cache/bazel/_bazel_arch/f2207b308c89ea5d32323052637210b1/external
+ cd /tmp/.cache/bazel/_bazel_arch/f2207b308c89ea5d32323052637210b1/external/com_github_bazelbuild_bazel_integration_testing
+ git reset --hard 55a6a70dbcc2cc7699ee715746fb1452788f8d3c
fatal: Could not parse object '55a6a70dbcc2cc7699ee715746fb1452788f8d3c'.
+ git fetch origin 55a6a70dbcc2cc7699ee715746fb1452788f8d3c:55a6a70dbcc2cc7699ee715746fb1452788f8d3c
fatal: 'origin' does not appear to be a git repository
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
ERROR: error loading package '': Encountered error while reading extension file 'tools/repositories.bzl': no such package '@com_github_bazelbuild_bazel_integration_testing//tools': Traceback (most recent call last):
File "/tmp/.cache/bazel/_bazel_arch/f2207b308c89ea5d32323052637210b1/external/bazel_tools/tools/build_defs/repo/git.bzl", line 69
_clone_or_update(ctx)
File "/tmp/.cache/bazel/_bazel_arch/f2207b308c89ea5d32323052637210b1/external/bazel_tools/tools/build_defs/repo/git.bzl", line 44, in _clone_or_update
fail(("error cloning %s:\n%s" % (ctx....)))
error cloning com_github_bazelbuild_bazel_integration_testing:
+ cd /tmp/.cache/bazel/_bazel_arch/f2207b308c89ea5d32323052637210b1/external
+ cd /tmp/.cache/bazel/_bazel_arch/f2207b308c89ea5d32323052637210b1/external/com_github_bazelbuild_bazel_integration_testing
+ git reset --hard 55a6a70dbcc2cc7699ee715746fb1452788f8d3c
fatal: Could not parse object '55a6a70dbcc2cc7699ee715746fb1452788f8d3c'.
+ git fetch origin 55a6a70dbcc2cc7699ee715746fb1452788f8d3c:55a6a70dbcc2cc7699ee715746fb1452788f8d3c
fatal: 'origin' does not appear to be a git repository
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
INFO: Elapsed time: 4.974s
FAILED: Build did NOT complete successfully (0 packages loaded)
```
* let's find out why it failed
```bash
[arch@archlinux bazel-watcher]$ grep rev-parse /tmp/.cache/bazel/_bazel_arch/f2207b308c89ea5d32323052637210b1/external/bazel_tools/tools/build_defs/repo/git.bzl
if ! ( cd '{dir}' && git rev-parse --git-dir ) >/dev/null 2>&1; then
[arch@archlinux bazel-watcher]$ cd /tmp/.cache/bazel/_bazel_arch/f2207b308c89ea5d32323052637210b1/external/com_github_bazelbuild_bazel_integration_testing
[arch@archlinux com_github_bazelbuild_bazel_integration_testing]$ git rev-parse --git-dir
/tmp/.cache/.git
[arch@archlinux com_github_bazelbuild_bazel_integration_testing]$ cd -
```
* let's fix git.bzl
```bash
[arch@archlinux bazel-watcher]$ sed -i -E 's/git rev-parse --git-dir/[[ "$(git rev-parse --git-dir)" == '.git' ]]/' /tmp/.cache/bazel/_bazel_arch/f2207b308c89ea5d32323052637210b1/external/bazel_tools/tools/build_defs/repo/git.bzl
[arch@archlinux bazel-watcher]$ grep rev-parse /tmp/.cache/bazel/_bazel_arch/f2207b308c89ea5d32323052637210b1/external/bazel_tools/tools/build_defs/repo/git.bzl
if ! ( cd '{dir}' && [[ "$(git rev-parse --git-dir)" == .git ]] ) >/dev/null 2>&1; then
```
* make sure that Bazel works again
```bash
[arch@archlinux bazel-watcher]$ ls -a /tmp/.cache/bazel/_bazel_arch/f2207b308c89ea5d32323052637210b1/external/com_github_bazelbuild_bazel_integration_testing
. ..
[arch@archlinux bazel-watcher]$ bazel --batch build :all
INFO: $TEST_TMPDIR defined: output root default is '/tmp/.cache/bazel' and max_idle_secs default is '15'.
Error: corrupt installation: file '/tmp/.cache/bazel/_bazel_arch/install/f20169627a8110e2cc3d005319e97c94/_embedded_binaries/embedded_tools/tools/build_defs/repo/git.bzl' modified. Please remove '/tmp/.cache/bazel/_bazel_arch/install/f20169627a8110e2cc3d005319e97c94' and try again.
[arch@archlinux bazel-watcher]$ touch -m -t 202712120101 /tmp/.cache/bazel/_bazel_arch/install/f20169627a8110e2cc3d005319e97c94/_embedded_binaries/embedded_tools/tools/build_defs/repo/git.bzl
[arch@archlinux bazel-watcher]$ bazel --batch build :all
INFO: $TEST_TMPDIR defined: output root default is '/tmp/.cache/bazel' and max_idle_secs default is '15'.
WARNING: /tmp/.cache/bazel/_bazel_arch/f2207b308c89ea5d32323052637210b1/external/com_github_bazelbuild_bazel_integration_testing/WORKSPACE:1: Workspace name in /tmp/.cache/bazel/_bazel_arch/f2207b308c89ea5d32323052637210b1/external/com_github_bazelbuild_bazel_integration_testing/WORKSPACE (@build_bazel_integration_testing) does not match the name given in the repository's definition (@com_github_bazelbuild_bazel_integration_testing); this will cause a build error in future versions
INFO: Analysed target //:go_prefix (6 packages loaded).
INFO: Found 1 target...
Target //:go_prefix up-to-date (nothing to build)
INFO: Elapsed time: 13.318s, Critical Path: 0.07s
INFO: Build completed successfully, 1 total action
[arch@archlinux bazel-watcher]$ ls -a /tmp/.cache/bazel/_bazel_arch/f2207b308c89ea5d32323052637210b1/external/com_github_bazelbuild_bazel_integration_testing
. .. AUTHORS bazel_integration_test bazel_integration_test.bzl bazel_version.bzl BUILD .ci CODEOWNERS CONTRIBUTING.md .git .gitignore go java javatests LICENSE README.md tools WORKSPACE
```
Closes #4358.
PiperOrigin-RevId: 181151078
|
|
|
|
|
|
|
| |
This fixes "type 'depset' is not iterable. Use the `to_list()` method
to get a list." warning.
Change-Id: I10bd791ce15445469afb9e12b2246be583c77a4b
|
|
|
|
|
|
|
|
|
| |
The `+` operator on dicts is deprecated and will be removed. This change makes
Bazel files compatible with the new behavior.
Fixes #4346.
PiperOrigin-RevId: 180702882
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to have --cpu=x64_windows_msys for selecting msys gcc toolchain,
this is a misuse of --cpu flag.
Instead, we should use --compiler flag to select C++ toolchain.
For example, --compiler=msvc-cl, --compiler=msys-gcc, --compiler=mingw-gcc
After this change, we can use mingw gcc toolchain by following steps:
1. In MSYS, install mingw by `pacman -S mingw-w64-x86_64-gcc`
2. Add /mingw64:/mingw64/bin into PATH
3. build with --compiler=mingw-gcc
Related:
https://github.com/bazelbuild/rules_go/issues/736
Change-Id: I4b5f77ce0698cfcafefe5d2ab17657f9c9e295d3
PiperOrigin-RevId: 180678829
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bazel's autoconf script adds -fno-canonical-system-headers to gcc's crosstool
in order to get output in '.d' files that can be properly verified by bazel.
To workaround the same issue in clang we have to use a different flag:
'-no-canonical-prefixes'.
The same issue arises with clang if it resides in the configured repository
(e.g., when it is downloaded via 'repository_ctx.download').
PiperOrigin-RevId: 180552155
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Generated crosstool previously used absolute paths for everything.
However, when using a compiler, local to the repository (e.g., downloaded via
'repository_ctx.download'), relative paths should be used to avoid absolute
paths that point into the crosstool repository.
Specifically, this patch contains the following changes:
1. Replaces absolute paths in 'cxx_builtin_include' with relative if includes
point inside the repository.
2. Removes the '-B<compiler-dir>' from 'compiler_flag' and 'linker_flag'
sections when compiler is inside the repository.
PiperOrigin-RevId: 180540359
|
|
|
|
|
|
|
|
|
|
|
|
| |
When --define EXECUTOR=remote is specified in bazel command, embedded
tools 'def_parser' will be compiled remotely from source.
Because def_parser itself is a cc_binary, if we want to compile it
remotely, to avoid cycle dependency it cannot be a dependency of
cc_toolchain. Therefore, we make it a dependency of cc rules.
Change-Id: I77faf77238f8edd3585d0e5e5c780b14e9782a40
PiperOrigin-RevId: 180534568
|
|
|
|
|
|
| |
cc_toolchain_type //tools/cpp:toolchain_type.
PiperOrigin-RevId: 179818065
|
|
|
|
|
|
| |
Closes #4282.
PiperOrigin-RevId: 179783690
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 179760609
|
|
|
|
|
|
|
| |
rt.jar etc. no longer exist, retrieve the default bootclasspath contents
using a Java program instead.
PiperOrigin-RevId: 179747945
|
|
|
|
|
|
|
| |
late bound default instead.
RELNOTES: None.
PiperOrigin-RevId: 179738235
|
|
|
|
|
|
| |
This makes sure the BUILD files we publish in https://github.com/bazelbuild/bazel-toolchains has the right license notice.
PiperOrigin-RevId: 179686473
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds a few extension points to cc_configure script with
the ultimate goal to allow downloading the compiler and other tools
used for C++ build before generating the crosstool.
Specifically, we make the following changes:
- Expose the implementation of a cc_autoconf repository rule under a
name of cc_autoconf_impl.
- Extend cc_autoconf_impl to allow overriding paths to build
tools (i.e. compilers, linkers, etc.)
- Allow to put any extra artifacts into the generated crosstool
repository. All files inside 'extra_tools' folder are added into
compiler_files, all_files and linker_files properties of the
generated crosstool, so that they are available for the crosstool.
With these extension one can do the following to download the
compilers used for the build and configure the crosstool:
- Create a repository_rule for the toolchain with a custom
implementation.
- In the implementation function of the repository rule:
+ Download the compilers and put them into `extra_tools` folder.
+ Run cc_autoconf_impl with overriden_tools set to relative paths
of the compiler and other build tools in the extra_tools folder.
Change-Id: I51af6b504578963b3e97bcdd1ccb6d0a5fed1c3e
PiperOrigin-RevId: 179675911
|
|
|
|
|
|
|
|
|
|
| |
After 8b3ba50246fed6ff13d70299fb039cc66be465c4, msys path should not
appear in CROSSTOOL, because Bazel won't translate it anymore.
Fix https://github.com/bazelbuild/bazel/issues/4318
Change-Id: I33d783a2ef14299e586856fefa2d68adce587045
PiperOrigin-RevId: 179667545
|
|
|
|
|
|
|
| |
And inject the correct toolchain for the current host_javabase into
tools.WORKSPACE.
PiperOrigin-RevId: 179618337
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 179596587
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 179577497
|
|
|
|
|
|
|
|
|
|
|
|
| |
instrumentation android_binary's AndroidManifest.xml references the correct package name of the instrumented android_binary.
During an instrumentation test, ART will use the targetPackage specified in the instrumentation APK's AndroidManifest to determine the application to be instrumented. We can perform this check in Bazel at execution time, before the apps are loaded onto the device.
See android_instrumentation_test_integration_test.sh for the e2e example.
GITHUB: https://github.com/bazelbuild/bazel/issues/903
RELNOTES: None.
PiperOrigin-RevId: 179564246
|