| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
| |
In hello-world_test, when executed inside a docker container, for about 2% of the runs the test.xml has an empty CDATA, instead of the expected "Hello, world!". I'm not sure still what exactly was the bug, but in any case this change simplifies the test execution code line, so if this doesn't fix it, at least further debugging will be easier.
I ran the test in a loop 1360 times, and the error did not reproduce once, which hints towards this fixing it, since for an unpatched Bazel it reproduced 7 times out of 293 runs.
TESTED=ran Bazel test in a loop
RELNOTES: None
PiperOrigin-RevId: 170702015
|
|
|
|
|
|
|
|
| |
...so that bazel does not complain about internal files when
run with --all_incompatible_changes.
Change-Id: I9a12a7ab0cd6a92351fe17addd601d531f203aff
PiperOrigin-RevId: 170694212
|
|
|
|
|
|
|
|
|
| |
interface_library_output_path flag set
We shouldn't apply this flag set to c++-link-executable action, it will only add a /IMPLIB:ignore option.
RELNOTES: None.
PiperOrigin-RevId: 170459781
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 170198788
|
|
|
|
|
|
|
|
|
|
|
|
| |
//tools/android/aar_embedded_jars_extractor.py now
supports long paths using the same
junction-creating trick as aar_resources_extractor
does.
Fixes https://github.com/bazelbuild/bazel/issues/3808
Change-Id: I2db25b0536ac3a97f4a04191bc398eb236923a7c
PiperOrigin-RevId: 170193093
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix a bug in the Android tool
aar_resources_extractor: open the compressed data
and the target file as file descriptores, rather
than using aar.extract.
This way we can shorten the directories in the
relative path of the extracted file, because we
can open the target file via a junction and thus
work around long path limitations.
//tools/android:aar_resources_extractor_test now
passes on Windows.
Change-Id: I9f5c7de2279ad8769e53e015b8334a58a76cd989
PiperOrigin-RevId: 170181143
|
|
|
|
|
|
|
|
|
| |
junction.TempJunction now can create all parent
directories of the junction target if they don't
exist.
Change-Id: I3e9cf34e78a3eb1ef9415036b791843a3b37f7c1
PiperOrigin-RevId: 170176180
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current implementation allows the gzip module to use the current
time as a timestamp. Python2 unfortunately doesn't expose this in the
tarfile module so it's easy to overlook.
This patch separates the gzip process by creating a separate file
object manually and bypassing the gzip compression in the tarfile
module.
Fixes #1844
Change-Id: I19b265bf55314d38bdd53ccf20c49ecfe6d7618b
PiperOrigin-RevId: 170077036
|
|
|
|
|
|
|
|
|
|
| |
Note that the support libraries are excluded on Windows, because Windows
runfiles are zipped and the support libraries are very big.
First step towards https://github.com/bazelbuild/bazel/issues/3663
RELNOTES: None
PiperOrigin-RevId: 170057391
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is to replace using USE_DYNAMIC_CRT env variable to configure
msvcrt linking in CROSSTOOL.
If user applies static_link_msvcrt feature to a specific target,
Bazel will choose the correct options for statically linking msvcrt.
If static_link_msvcrt is not specified, Bazel uses options for dynamically linking
msvcrt by default.
https://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx
Change-Id: Ia078dfb528de9ffdd8a11d392db9eb3f34463b09
PiperOrigin-RevId: 170021927
|
|
|
|
|
|
|
|
|
|
|
| |
Also, bundle snapshots.img in Bazel since it was removed from the SDK.
Part of the fix for https://github.com/bazelbuild/bazel/issues/3504
Note that this will require an update to unified launcher at https://github.com/google/android-testing-support-library
RELNOTES: None
PiperOrigin-RevId: 169937694
|
|
|
|
|
|
|
|
|
|
|
| |
This patch sets the mtime attribute of gzip explicitly to zero.
Python2 doesn't expose this via the tarfile module so we have to
create an explicit gzip instance.
Fixes #3723
Change-Id: I4ce38a317bb92481562b67075d1272f1aebdf9d6
PiperOrigin-RevId: 169881504
|
|
|
|
|
|
|
| |
Tested manually (with a test that doesn't emit undeclared outputs), and added a test that failed before and passes after the test-setup.sh change.
RELNOTES: N/A
PiperOrigin-RevId: 169687782
|
|
|
|
|
|
|
|
|
| |
Before, linkstamping compile actions were hardcoded in bazel and assumed
gcc/clang and bash. This cl removes gcc/clang assumptions by using feature
configuration.
RELNOTES: None.
PiperOrigin-RevId: 169685949
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The legacy docker_build was removed from bazel_tools
but we need to use it for our integration test so refer
to the one in the main repository.
Also restore the visibility, just excluding it from
bazel_tools is enough and docker_pull needs to call it
from other repository.
Change-Id: I8a8a5781859960030ae996db95fbaf9c54ec596a
PiperOrigin-RevId: 169664916
|
|
|
|
|
|
|
|
|
|
| |
For the time being, all C++ links will provide ObjC core libraries on the command line,
via having the link actions imply 'contains_objc_sources', which is a built-in feature
that is in the process of being enabled automatically when objective-C/C++ sources
are involved in the build. Once that happens, the 'imply' directives will be removed.
RELNOTES: Stop using --undefined dynamic_lookup in Apple links. Enables unresolved symbol errors.
PiperOrigin-RevId: 169437020
|
|
|
|
|
|
|
|
|
|
|
| |
When copy_dynamic_libraries_to_binary is enabled, we copy the shared
libraries required by the binary to the binary's directory.
Bazel will throw errors if there are confilct actions generating the
same artifacts.
Change-Id: I09a5a599ca0ec7a67efd49d5aa89481450fa4e90
PiperOrigin-RevId: 169364498
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR to Bazel.
After this change:
- Any files written to the TEST_UNDECLARED_OUTPUTS_DIR directory will be zipped up and added to an outputs.zip file under bazel-testlogs.
- Files will be listed in a MANIFEST file under bazel-testlogs.
- Any files written to TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR will be concatenated together into an ANNOTATIONS file under bazel-testlogs.
This provides a channel for tests to provide extra information outside of the test output itself. This is useful for things like verbose server logs.
Note: The //src/test/shell/bazel:bazel_test_test target has a pre-existing breakage (see https://github.com/bazelbuild/bazel/issues/3727). But the new tests pass.
RELNOTES: Tests can now write files to TEST_UNDECLARED_OUTPUTS_DIR and TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR and these will be reflected under bazel-testlogs.
PiperOrigin-RevId: 169282528
|
|
|
|
| |
PiperOrigin-RevId: 168835640
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks clang_tidy.
*** Original change description ***
Introduce -c source_file -o output_file build variables
Prior to this cl CompileCommandLine would (almost) unconditionally emit -c and
-o flags. This cl removes this logic and relies on crosstool to emit these
flags. This is another small step towards platform independent C++ rules.
Memory use is not affected, since the build variables used by this cl are already
exposed, this cl just forces crosstools to use it.
RELNOTES: None.
PiperOrigin-RevId: 168834576
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Working towards: https://github.com/bazelbuild/bazel/issues/3311
When building dynamic library on Windows, Bazel builds an import library
and a DLL.
Bazel provides a feature called windows_export_all_symbols, if this
feature is enabled(and no_windows_export_all_symbols is not) for a
cc_library, then Bazel parses object files of that cc_library to generate
a DEF file that will be used during linking time to export symbols from
DLL. This feature can be specified at crosstool, package, target and
command line level.
A few differences from Unix platforms:
1. We don't build the shared library on Windows by default, users have to
specifiy --output_groups=dynamic_library for building dynamic libraries.
This output group is also available on other platforms.
2. By default, cc_test is dynamically linked on Unix, but it will be
statically linked on Windows by default. (meaning the default value of
linkstatic in cc_test is 1 on Windows, and 0 on other platforms)
3. For global data symbols, __declspec(dllimport) must still be used in
source files.
Remaining issues:
1. Extensions for import library and DLL are not correct yet.
2. DLLs are not guaranteed to be available during runtime yet.
3. Diamond problem
If a cc_library A is specified as linkstatic=0, then no dynamic library
will be built for it, so if another cc_library B depends on it, A will
be statically linked into B, and if a cc_binary C depends on B, A will
also be statically linked into C and B will be dynamically linked to C.
This is wrong because A is duplicated in both B and C.
It is essentially a diamond problem describled in C++ Transitive Library.
(https://docs.google.com/document/d/1-tv0_79zGyBoDmaP_pYWaBVUwHUteLpAs90_rUl-VY8/edit?usp=sharing)
Hopefully, we can avoid this by using cc_shared_library rule in future.
Change-Id: I23640d4caf8afe65d60b1522af6368536d7a8408
PiperOrigin-RevId: 168829958
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks Bazel building itself on FreeBSD, also #3739.
*** Original change description ***
Introduce empty "toolchain_category" rule for labels that will be used as
categories of toolchains for the purpose of toolchain selection.
Up to now, we've used the native toolchain_type rule for this purpose. That rule depends on a number of configuration fragments that supply build variables - we don't want toolchains to need to depend on those fragments as well. E.g. toolchain_type depends on JvmConfiguration, but we would like toolchains to work with --experimental_disable_jvm.
PiperOrigin-RevId: 168810566
|
|
|
|
|
|
|
|
| |
(https://docs.bazel.build/versions/master/test-encyclopedia.html) mentioned that when running tests the `PWD` should be `$TEST_SRCDIR/workspace-name`
Closes #3616.
PiperOrigin-RevId: 168806570
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this cl CompileCommandLine would (almost) unconditionally emit -c and
-o flags. This cl removes this logic and relies on crosstool to emit these
flags. This is another small step towards platform independent C++ rules.
Memory use is not affected, since the build variables used by this cl are already
exposed, this cl just forces crosstools to use it.
RELNOTES: None.
PiperOrigin-RevId: 168671507
|
|
|
|
|
|
|
|
|
| |
... and lock down the visibility to only the Bazel project, please see
https://github.com/bazelbuild/rules_docker instead.
RELNOTES[INC]: @bazel_tools//tools/build_defs/docker:docker.bzl is no longer available, please see https://github.com/bazelbuild/rules_docker.
PiperOrigin-RevId: 168650438
|
|
|
|
|
|
|
|
| |
categories of toolchains for the purpose of toolchain selection.
Up to now, we've used the native toolchain_type rule for this purpose. That rule depends on a number of configuration fragments that supply build variables - we don't want toolchains to need to depend on those fragments as well. E.g. toolchain_type depends on JvmConfiguration, but we would like toolchains to work with --experimental_disable_jvm.
PiperOrigin-RevId: 168577759
|
|
|
|
|
|
|
|
|
| |
This cl removes hardcoded --sysroot flag generation from bazel when constructing
command line for C++ actions. The hardcoded flag is still exposed to Skylark (to
stay backwards compatible).
RELNOTES: None.
PiperOrigin-RevId: 168346711
|
|
|
|
|
| |
RELNOTES: The swift_library rule that is distributed with Bazel has been deleted. Users who wish to compile Swift should use the rules in https://github.com/bazelbuild/rules_apple instead.
PiperOrigin-RevId: 168032330
|
|
|
|
|
| |
RELNOTES: The apple_genrule rule that is distributed with Bazel has been deleted. Users who wish to use genrules with Xcode's DEVELOPER_DIR set should use the rules in https://github.com/bazelbuild/rules_apple instead.
PiperOrigin-RevId: 168027826
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
user_compile_flags
Also add magic to a feature named 'unfiltered_compile_flags' so the flags
expanded from it are not subject to nocopt filtering.
This is encore of https://github.com/bazelbuild/bazel/commit/268c0bcbf79f9f3f72d95fa51af0f1b18c5ce29e that was rolled back because it regressed
memory.
RELNOTES: None.
PiperOrigin-RevId: 167989075
|
|
|
|
|
|
|
|
| |
PlatformConfiguration is made a legal configuration fragment for every rule class.
Add a default "dummy" c++ toolchain to prevent resolution errors when legacy toolchain selection logic is used. Add toolchain mocks to java and shell tests.
PiperOrigin-RevId: 167901210
|
|
|
|
|
|
|
| |
This is useful so that Skylark code that depends on this rule can decide if it's there or not (as opposed to failing due to a missing dependency)
RELNOTES: None.
PiperOrigin-RevId: 167839197
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Rollback since this change is based on https://github.com/bazelbuild/bazel/commit/268c0bcbf79f9f3f72d95fa51af0f1b18c5ce29e, which is rollbacked due to a performance reason
RELNOTES: None.
PiperOrigin-RevId: 167836715
|
|
|
|
| |
PiperOrigin-RevId: 167751263
|
|
|
|
|
|
|
|
| |
Care is taken so that this is only present when building with Bazel at HEAD
such that Bazel can still be built with its released version.
RELNOTES: None.
PiperOrigin-RevId: 167713922
|
|
|
|
|
|
|
|
|
| |
https://github.com/bazelbuild/bazel/commit/268c0bcbf79f9f3f72d95fa51af0f1b18c5ce29e
Fixes #3693
RELNOTES: None.
PiperOrigin-RevId: 167704700
|
|
|
|
|
|
|
|
|
| |
Split collect, concurrent, vfs, windows into package-level BUILD files.
Move clock classes out of "util", into their own Java package.
Move CompactHashSet into its own Java package to break a dependency cycle.
Give nestedset and inmemoryfs their own package-level BUILD files.
PiperOrigin-RevId: 167702127
|
|
|
|
|
|
|
|
|
|
| |
user_compile_flags
Also add magic to a feature named 'unfiltered_compile_flags' so the flags
expanded from it are not subject to nocopt filtering.
RELNOTES: None.
PiperOrigin-RevId: 167587189
|
|
|
|
|
|
|
| |
Fixes https://github.com/bazelbuild/bazel/issues/3672
RELNOTES: None
PiperOrigin-RevId: 167581302
|
|
|
|
|
|
| |
Closes #3640.
PiperOrigin-RevId: 167578762
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
aar_resources_extractor now supports long paths
on Windows.
If the script needs to extract a file from the
AAR where the destination path is too long, the
script will:
1. create a temporary junction under a short path,
pointing to the destination directory (which
has a long path)
2. extract the file under the junction
3. delete the junction and the temp directory
See https://github.com/bazelbuild/bazel/issues/3659
Change-Id: Ie85665b360a6514afaac546aaec8869224fe9d06
PiperOrigin-RevId: 167545085
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Change-Id: Ib90ce99cc2e229bbe749130dbde517a075d6e333
PiperOrigin-RevId: 167319258
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Unix-like platforms, we can execute deploy jars
just like normal binaries, but on Windows we
cannot because ".jar" is not an executable
extension. Therefore we cannot run
SingleJar_deploy.jar in a genrule.cmd.
In this change I do the following changes to:
//tools/android/BUILD.tools:
- add a java_import rule that wraps the SingleJar
deploy jar
- add a java_binary that runtime-depends on the
jar
- fix the ":gen_java_lang_extras_jar" genrule to
run the java_binary instead of the deploy jar
See https://github.com/bazelbuild/bazel/issues/3659
Change-Id: Ie035e721deb696bbd4130b3612695a10dd9c2b4d
PiperOrigin-RevId: 167281195
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
fix the downstream breaks that led to the initial rollback
Change-Id: Ib90ce99cc2e229bbe749130dbde517a075d6e333
PiperOrigin-RevId: 167247311
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks rules_go CI
*** Original change description ***
Rollforward of c++ toolchain-relevant BUILD file and Bazel mocking changes. That is, a c++ toolchain is added, but a Bazel dependency on that toolchain is not.
PiperOrigin-RevId: 167198874
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 167142666
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 167027537
|
|
|
|
|
|
| |
That is, a c++ toolchain is added, but a Bazel dependency on that toolchain is not.
PiperOrigin-RevId: 167006332
|
|
|
|
| |
PiperOrigin-RevId: 166966182
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 166868614
|