| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
non-hermetic events that happen as part of repository rules).
Defining representation for Execute events for workspace logging.
In the future:
- Add more events
- Allowing to specify log file rather than dumping to INFO
- Log levels, full or alerts only
RELNOTES: None
PiperOrigin-RevId: 204748436
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 202644613
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This skydoc rewrite uses an actual skylark interpreter with a faked build API (implementing the actual build API that Bazel uses).
There's a lot left to do here, this is a barebones start.
For example, this does not yet handle:
- load() statements
- non-global build API elements (e.g. apple_common)
- output of any rule information other than attribute names
- markdown output format
RELNOTES: None.
PiperOrigin-RevId: 202187207
|
|
|
|
|
|
|
| |
As //tools/defaults will be deprecated soon. All usages of //tools/defaults:jdk and //tools/defaults:java_toolchain should be replaced by corresponding targets in //tools/jdk/BUILD package
RELNOTES:none
PiperOrigin-RevId: 202114489
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Closes #5403.
PiperOrigin-RevId: 201007405
|
|
|
|
|
|
|
|
| |
For now, the tool simply displays the log as text.
TESTED=ran it
RELNOTES: A tool to parse the Bazel execution log.
PiperOrigin-RevId: 200718299
|
|
|
|
|
|
|
|
|
|
|
| |
- Updates the embedded JDK to Azul Zulu 9.0.7
- All integration tests use Bazel with the embedded JDK
Also updated: http://storage.googleapis.com/bazel-mirror/openjdk/index.html
Closes #5312, #5314, #5315
PiperOrigin-RevId: 200055008
|
|
|
|
|
|
|
| |
Small self-contained part of the debug server (see unknown commit for the
larger picture).
PiperOrigin-RevId: 197140094
|
|
|
|
|
|
|
| |
It is a left over from long ago, and nothing should be using it as the
swift support is now via skylark rules and no longer native code.
PiperOrigin-RevId: 196541787
|
|
|
|
|
|
| |
and continue to use the embedded JDK as the default host_javabase.
PiperOrigin-RevId: 196471714
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 196272337
|
|
|
|
| |
PiperOrigin-RevId: 196266567
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this commit:
- split //src/test/shell:shell_utils_test into a
symlink-specific part and the rest
- use the Bash runfiles library
- add "windows_tests" and "all_windows_tests"
targets as we do in other platforms (e.g. in
//src:BUILD)
See https://github.com/bazelbuild/bazel/issues/4930
See https://github.com/bazelbuild/bazel/issues/4292
Change-Id: I111a7fed223f1f9b767dc6411389465f8da3e043
PiperOrigin-RevId: 194395011
|
|
|
|
| |
PiperOrigin-RevId: 193052121
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was added during the JDK 7->8 transition to improve the diagnostic
when an older-than-supported host_javabase was used. The version number
handling doesn't work with JDK 9 (see [1]), and using Bazel binaries
with a bundled host_javabase avoid the error entirely so the message
is less important.
[1] http://openjdk.java.net/jeps/223
PiperOrigin-RevId: 190944476
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 189973158
|
|
|
|
| |
PiperOrigin-RevId: 189023695
|
|
|
|
|
| |
RELNOTES:n/a.
PiperOrigin-RevId: 186043433
|
|
|
|
|
| |
Change-Id: I1fa7867ffb08af95c1eef5ae3e32cff34292328b
PiperOrigin-RevId: 185189976
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We'll just replace them with either native support for running tests inside
Docker containers on CI or with VMs running the operating system.
This gets rid of the "let's download 8 GB of Docker images" step when running
`bazel build //...`.
RELNOTES: None.
Closes #4506.
PiperOrigin-RevId: 183078052
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 180826643
|
|
|
|
|
|
|
| |
This is now possible because the Bazel release now supports TemplateVariableInfo.
RELNOTES: None.
PiperOrigin-RevId: 178360631
|
|
|
|
|
|
|
|
| |
This is because I want to add another remote execution related tool, the remote_client, which will use the Remote Execution API to fetch blobs from a remote cache. I will use this tool as part of end-to-end tests for remote execution.
TESTED=remote integration tests, presubmit
RELNOTES: None
PiperOrigin-RevId: 177995895
|
|
|
|
|
|
|
| |
This will enable an easier transition from checked-in BUILD files to ones generated by copybara.
RELNOTES: None
PiperOrigin-RevId: 177514519
|
|
|
|
|
|
|
|
|
|
|
| |
to rules that use the $(JAVA) or the $(JAVABASE) Make variable.
This is necessary because a future Blaze version will require this for rules that use said Make variables. This incompatible change can be tested today by adding the --noexperimental_enable_jvm_configuration_make_variables command line option to Blaze.
This change is part of a large-scale change ([]
RELNOTES: None.
PiperOrigin-RevId: 176834987
|
|
|
|
| |
PiperOrigin-RevId: 174482602
|
|
|
|
|
|
| |
This is no longer maintained and the CI is turned down.
PiperOrigin-RevId: 174456265
|
|
|
|
|
|
| |
When --define EXECUTOR=remote is specified in bazel command, embedded tool singlejar and ijar will be compiled remotely from source.
PiperOrigin-RevId: 174195094
|
|
|
|
|
|
|
|
|
|
|
|
| |
Create sourceable runfiles.sh that implements
rlocation and a couple other helper functions for
shell scripts.
Change-Id: Ifcf9ee86ed63afe2ce655be596ac781494660398
RELNOTES[NEW]: runfiles, sh: Shell scripts may now depend on //src/tools/runfiles:runfiles_sh_lib and source runfiles.sh. The script defines the `rlocation` function which returns runfile paths on every platform.
PiperOrigin-RevId: 171816037
|
|
|
|
|
|
|
|
|
| |
Fixes https://github.com/bazelbuild/bazel/issues/3777
Also adds a proguard integration test so that hopefully we notice next time it breaks.
RELNOTES: Updated Android proguard to 5.3.3. It now works with android-24+.
PiperOrigin-RevId: 171162295
|
|
|
|
|
|
|
| |
The same binary is *outside* of the zip so there is no point in repeating it.
RELNOTES: None.
PiperOrigin-RevId: 170461181
|
|
|
|
| |
PiperOrigin-RevId: 169563077
|
|
|
|
|
|
|
| |
Fixes https://github.com/bazelbuild/bazel/issues/3742
Change-Id: Ibfa1909e387e9734040b00523cc9388a386e0bf4
PiperOrigin-RevId: 169538023
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add recursive test_suite rules for all tests that
ci.bazel.io runs for Windows, and set the
top-level test_suite as the CI test target.
Doing so shortens the command line and works
around https://github.com/bazelbuild/bazel/issues/3742
I verified that the old set of tests are the same
as the new set.
Change-Id: Id8d5da3f0c03c9b8969a9f8e1e9a3096888365aa
PiperOrigin-RevId: 169242858
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 ***
Roll-forward with fix
*** Original change description ***
Automated rollback of commit f5b8281f1f7599c67476663887db909a4206710e.
*** Reason for rollback ***
Read the wrong log, it is not timing out, actual failure.
*** Original change description ***
Open-source src/test/skylark/...
This was means to be open-sourced from the beginning but an error in our
set-up hide it from the open-source tree.
PiperOrigin-RevId: 168526758
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Read the wrong log, it is not timing out, actual failure.
*** Original change description ***
Open-source src/test/skylark/...
This was means to be open-sourced from the beginning but an error in our
set-up hide it from the open-source tree.
PiperOrigin-RevId: 168428572
|
|
|
|
|
|
|
| |
This was means to be open-sourced from the beginning but an error in our
set-up hide it from the open-source tree.
PiperOrigin-RevId: 168427396
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Change-Id: I3fce66ec2e63d152aafc0cf9ea067d6dbf1245f7
PiperOrigin-RevId: 167484075
|
|
|
|
|
|
|
|
|
| |
This and further changes may contain minor modifications to BUILD files that
don't serve any apparent purpose. The reason for these changes is that we're
switching from checked-in BUILD files to generated BUILD files, and there may
be small differences between these files.
PiperOrigin-RevId: 166684362
|
|
|
|
|
|
|
|
|
| |
This change reduces the size taken up in the bazel binary by Android tools deploy jars from 38.2 mb to 9.8 mb, which is 15% of the bazel binary size. Also, some minor cleanups of our BUILD files.
https://github.com/bazelbuild/bazel/issues/2385
RELNOTES: None
PiperOrigin-RevId: 166373241
|
|
|
|
|
|
|
|
| |
This commit introduces checking of naming conventions,
i.e. upper and lower snake case.
RELNOTES: None
PiperOrigin-RevId: 166073284
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It can only pack to zip for now (packing to tar is
not trivial and I haven't figured it out yet).
This allows building //:bazel-distfile on Windows.
Previously it was either timing out or taking so
long that it was unbearable (over 10 minutes).
I never waited long enough to see it build.
The new Python version runs under just a few
seconds.
Change-Id: I3264eb7132dd58c581c4216e5bbab035a79d716d
PiperOrigin-RevId: 164954162
|
|
|
|
|
|
|
|
|
| |
We'll use the extracted functions in the upcoming
Python-based reincarnation of the
//:bazel-distfile rule.
Change-Id: I5140938ae4af50f62fb695b5b96cd41f3cd939ef
PiperOrigin-RevId: 164950515
|
|
|
|
| |
PiperOrigin-RevId: 163538636
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change:
1. Added launcher to @bazel_tools
If the host platform is Windows, we use a prebuilt launcher.exe
, otherwise the launcher needs to be built with MSVC first.
2. Launching sh_binary using native launcher.
Change-Id: I5a63135455057fbfe04ff0cce7ec7994ef0c347a
PiperOrigin-RevId: 163442540
|