| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
This is functionally equivalent, but ~30x faster on Windows, ~2x faster on macOS and ~1.5x faster on Linux.
RELNOTES: None.
Change-Id: Ib4a7e10400a3955e47772425acfce2d9530de462
PiperOrigin-RevId: 163346634
|
|
|
|
|
|
|
| |
It now exists as a separate project at
https://github.com/bazelbuild/migration-tooling.
PiperOrigin-RevId: 162970509
|
|
|
|
|
|
|
|
|
|
| |
(https://github.com/bazelbuild/bazel/blob/master/tools/cpp/lib_cc_configure.bzl#L106-L107)), forcing bazel to use the `SingleJar_deploy.jar` java implementation of SingleJar fixes this issue.
I suspect 32-bit Unix has the same issue, which could be fixed by adding the same configuration for `piii`, but I don't have a 32-bit x86 system to test it on. But if anyone is here by Googling the above error code, try replacing all the `arm` references in this pull request with `piii`!
Closes #3382.
PiperOrigin-RevId: 162923371
|
|
|
|
|
|
|
|
| |
The native launcher is implemented based on this design doc:
https://docs.google.com/document/d/1z6Xv95CJYNYNYylcRklA6xBeesNLc54dqXfri0z0e14/edit?usp=sharing
Change-Id: I83bae844f792a587ce0e342a3c0f238b760afeaa
PiperOrigin-RevId: 162736269
|
|
|
|
|
|
|
|
|
| |
https://github.com/bazelbuild/bazel/pull/3363#issuecomment-314774384
Closes #3369.
Change-Id: I52c7c39db13131bfc343666fbd05840815ee7fa8
PiperOrigin-RevId: 162478002
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The script more logically belongs in
src/main/native/windows than in src/main/native.
Also move the //src/main/native:windows_jni rule
into //src/main/native/windows:windows_jni, so the
logic of building the JNI library is fully
contained in that package.
Change-Id: I96e19003932cc0ddc5af3471b0b31a1aec09b8fa
PiperOrigin-RevId: 160876594
|
|
|
|
|
|
|
|
|
|
| |
The genrule //src:derived_java_srcs so far assumed to find the
needed tool jar(1) on PATH. This, however, is not true in all
setups. Instead, use jar from JAVABASE, which should be the correct
toolchain to be used on the execution platform. Fixes #3284.
Change-Id: I1f972f819786b511237c448a6c57484a76f4118b
PiperOrigin-RevId: 160634222
|
|
|
|
|
|
|
|
| |
Fix the failure at
http://ci.bazel.io/view/Bazel%20bootstrap%20and%20maintenance/job/Bazel/PLATFORM_NAME=windows-msvc-x86_64/1620/console
RELNOTES: None.
PiperOrigin-RevId: 160504102
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a better location and tools/cpp is packaged in embedded_tools that make the test ends-up in embedded_tools, which is requiring network access
to build embedded_tools!
Side-effect: have to correctly mock the bazel workspace file on a couple
of tests.
This is blocking on https://bazel-review.googlesource.com/c/12350/
PiperOrigin-RevId: 160265524
|
|
|
|
|
|
|
| |
Deletes last code references to xcodegen tool as well as tool itself.
RELNOTES: None.
PiperOrigin-RevId: 160137807
|
|
|
|
|
|
|
|
|
|
| |
Please refer to patch set 9 and its CI run for usage and test
results. In practice, users should create their own java_toolchain
rule in their project's BUILD file, and set the two attributes like
above instead of modifying //tools/jdk/BUILD.
Change-Id: Ic880f243086b00a58d453a8139ba4c957fe54bc7
PiperOrigin-RevId: 159694649
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The C implementation of singlejar verifies that it is built for a
supported system; currently those are 64-bit linux and apple systems.
However, the code is portable enough that it can easily be adapted to
run on 64-bit FreeBSD systems as well. In fact, only the path of a
single header file is different, and we need to link with -lm.
Fixes #3096.
Change-Id: Id69542ad940f1161aceb55eb8f5dabda2f486747
PiperOrigin-RevId: 158533955
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows writing integration tests in Python
rather than shell, so we can avoid
https://github.com/bazelbuild/bazel/issues/3148
This change also adds a test to verify that
running "bazel info server_pid" twice yields the
same PID. Again, this is testing that we indeed
avoid the aformentioned bug.
Change-Id: Ic800965b16ab87179370fd2cd43908286120e8d5
PiperOrigin-RevId: 158517192
|
|
|
|
|
| |
Change-Id: I9652195e3f8d6f7912a1c52880f23114d34c6ebf
PiperOrigin-RevId: 158439371
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Use Java implementation of singlejar on FreeBSD, and roll forward change 157473007.
*** Original change description ***
Automated g4 rollback of commit d894345ed88f8adce600b66a310b5210d0bcb59c.
*** Reason for rollback ***
Breaks Bazel on FreeBSD: http://ci.bazel.io/view/Dashboard/job/Bazel/JAVA_VERSION=1.8,PLATFORM_NAME=freebsd-11/1542/console
*** Original change description ***
Use cc implementation of singlejar except on Windows.
Change-Id: Ie4a2db2a6fa1ea86f4bdd42cd806f6804a0c56d4
PiperOrigin-RevId: 157729503
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks Bazel on FreeBSD: http://ci.bazel.io/view/Dashboard/job/Bazel/JAVA_VERSION=1.8,PLATFORM_NAME=freebsd-11/1542/console
*** Original change description ***
Use cc implementation of singlejar except on Windows.
Change-Id: Ie4a2db2a6fa1ea86f4bdd42cd806f6804a0c56d4
PiperOrigin-RevId: 157567871
|
|
|
|
|
|
|
| |
and fixes some of J2ObjC's implicit deps to correctly reference the embedded tools.
RELNOTES: Partially fixes external J2ObjC support.
PiperOrigin-RevId: 157503022
|
|
|
|
|
| |
Change-Id: Ie4a2db2a6fa1ea86f4bdd42cd806f6804a0c56d4
PiperOrigin-RevId: 157473007
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 156113782
|
|
|
|
|
|
|
|
|
| |
That way we can detect Linux and use it in select().
I would like to use as part of https://bazel-review.googlesource.com/10490
Change-Id: Ifa88626e906a52af55ec8e85139b8223b556382f
PiperOrigin-RevId: 155868359
|
|
|
|
|
| |
Change-Id: Iad1e07ad55d5304d7c3dbb8bdab856728a91432d
PiperOrigin-RevId: 155375893
|
|
|
|
| |
PiperOrigin-RevId: 154078281
|
|
|
|
|
|
|
| |
Fixes #2848.
RELNOTES: None.
PiperOrigin-RevId: 153692641
|
|
|
|
|
|
|
|
|
|
|
| |
It is no longer used since --use_singlejar_apkbuilder is the default.
A future change will remove apkbuildermain from the Bazel codebase.
4MB bazel binary size savings! :)
RELNOTES: None
PiperOrigin-RevId: 153079733
|
|
|
|
|
|
|
|
|
| |
xcode src directories
There's no value in having these copied over from src/tools to tools/objc separately.
RELNOTES: None.
PiperOrigin-RevId: 153060955
|
|
|
|
|
|
|
|
|
| |
Make Java tool jars available from @bazel_tools.
Now users can point to default Java tool jars in customized
java_toolchain rule defined in project's BUILD file.
PiperOrigin-RevId: 152012191
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks Java 7 tests:
ERROR: missing input file '@bazel_tools//tools/jdk:JavaBuilder_deploy.jar'
http://ci.bazel.io/job/bazel-tests/BAZEL_VERSION=HEAD-jdk7,PLATFORM_NAME=linux-x86_64/670/console
*** Original change description ***
Make Java tool jars available from @bazel_tools.
Now users can point to default Java tool jars in custmized
java_toolchain rule defined in project's BUILD file.
PiperOrigin-RevId: 151699090
|
|
|
|
|
|
|
|
|
|
|
| |
Now users can point to default Java tool jars in custmized
java_toolchain rule defined in project's BUILD file.
--
Change-Id: I064c9646e8681a3f5669d7163b1b3cb5cc0b16b7
Reviewed-on: https://cr.bazel.build/9250
PiperOrigin-RevId: 151422924
MOS_MIGRATED_REVID=151422924
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
No longer needed, as the original tool was re-introduced in Xcode 8.3 beta 5
*** Original change description ***
Introduce swift-stdlib-tool replacement
* swift-stdlib-tool is a utility that, given a binary, walks its dynamic library deps graph and picks everything that is used by Swift runtime. This tool is being removed from Xcode 8.3, hence the replacement.
* The new tool has a different command line interface, but keeps backwards compatibility with native Bazel code through changes in the wrapper script. The wrapper script is still needed to handle xcrun ENV stuff.
--
PiperOrigin-RevId: 151052031
MOS_MIGRATED_REVID=151052031
|
|
|
|
|
|
|
|
|
|
| |
Allow the local version of local remote build server to pick up
the temporary Docker override flags and start a command from
within a docker container.
--
PiperOrigin-RevId: 150456019
MOS_MIGRATED_REVID=150456019
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We're using Azul Systems, Inc.'s Zulu® OpenJDK build[1], as it's a good
vanilla build of OpenJDK available for our three most important
platforms:
zulu8.20.0.5-jdk8.0.121-linux_x64.tar.gz
zulu8.20.0.5-jdk8.0.121-macosx_x64.zip
zulu8.20.0.5-jdk8.0.121-win_x64.zip
You can build & run a Bazel binary with an embedded JDK by simple doing:
bazel build //src:bazel_with_jdk
bazel-bin/src/bazel_with_jdk info
The "bazel license" command prints the license of the embedded OpenJDK.
We mirror the binaries and sources of the OpenJDK used for bundling on
this website:
https://bazel-mirror.storage.googleapis.com/openjdk/index.html
RELNOTES: Bazel can now be built with a bundled version of the OpenJDK.
This makes it possible to use Bazel on systems without a JDK, or where
the installed JDK is too old.
[1] http://www.azul.com/downloads/zulu/
--
PiperOrigin-RevId: 150440467
MOS_MIGRATED_REVID=150440467
|
|
|
|
|
|
|
|
|
|
| |
* swift-stdlib-tool is a utility that, given a binary, walks its dynamic library deps graph and picks everything that is used by Swift runtime. This tool is being removed from Xcode 8.3, hence the replacement.
* The new tool has a different command line interface, but keeps backwards compatibility with native Bazel code through changes in the wrapper script. The wrapper script is still needed to handle xcrun ENV stuff.
--
PiperOrigin-RevId: 149691879
MOS_MIGRATED_REVID=149691879
|
|
|
|
|
|
|
|
|
|
| |
a testbed of upcoming changes, without breaking existing test targets.
To use the alternate test runner a java test should add the tag "experimental_testrunner" and depend on "@bazel_tools//tools/jdk:ExperimentalTestRunner_deploy.jar" (instead of @bazel_tools//tools/jdk:TestRunner_deploy.jar)
--
PiperOrigin-RevId: 149536298
MOS_MIGRATED_REVID=149536298
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After this change, a msys bazel can be built with
a MSVC-default Bazel by adding --cpu=x64_windows_msys --host=x64_windows_msys
See https://github.com/bazelbuild/bazel/issues/2627
--
Change-Id: Iaa82bf4dd911c5740b98d3b2739dfccca6203f79
Reviewed-on: https://cr.bazel.build/9293
PiperOrigin-RevId: 149532274
MOS_MIGRATED_REVID=149532274
|
|
|
|
|
|
|
|
|
|
|
| |
These targets are unneeded and do not build without an android_sdk_repository
set up.
This issue was identified in https://github.com/bazelbuild/bazel/issues/2559.
--
PiperOrigin-RevId: 148251416
MOS_MIGRATED_REVID=148251416
|
|
|
|
|
|
|
|
| |
magic artifact.
--
PiperOrigin-RevId: 147830857
MOS_MIGRATED_REVID=147830857
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 147159416
MOS_MIGRATED_REVID=147159416
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 145524911
MOS_MIGRATED_REVID=145524911
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add tests for the AsExecutablePathForCreateProcess
method, since its logic is pretty complex.
Unfortunately testing it also requires complex
logic, as we need to test what exactly happens
when the input path is shorter than MAX_PATH or
when it's longer than it. To test that reliably,
we need a base path that we know will not get
shortened. Creating that base path under the temp
directory is a nightmare, we need to:
(1) retrieve the temp dir, shorten it so we know
that it won't be shortened further
(2) keep creating subdirectories that have a short
name so they also won't get shortened, but keep
the entire path below MAX_PATH while leaving
enough space for a file name in the end
(3) append a file name such that the path is just
below MAX_PATH, or is exactly that long, or is
longer than it. Because of steps (1) and (2) we
can be sure that no other component in the path
will get shortened, so we can test exactly what's
going on with the shortener logic and its error
handling. But oh boy is it complicated.
Side note, we need to use the Widechar WinAPI
functions to create/delete the directories and
files, because the POSIX API on Windows appears to
be backed by the ASCII API functions, so
attempting to `mkdir` with a path longer than
CreateDirectoryA's limit is going to fail.
But on the positive side, adding tests caught two
bugs in the method, so we have that going for us
which is nice.
See https://github.com/bazelbuild/bazel/issues/2107
See https://github.com/bazelbuild/bazel/issues/2181
--
PiperOrigin-RevId: 144823029
MOS_MIGRATED_REVID=144823029
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 144053696
MOS_MIGRATED_REVID=144053696
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Rolling forward, intentionally breaking loading phase (and therefore `bazel fetch`) for android_binary in Bazel if no android_sdk_repository is set up.
Will not submit until Tensorflow's use case is cleaned up in https://github.com/tensorflow/tensorflow/pull/6225.
--
PiperOrigin-RevId: 142068703
MOS_MIGRATED_REVID=142068703
|
|
|
|
|
|
|
|
| |
We are no longer using the checked-in apksigner jar, instead we are now reading this JAR from the Android build tools. A follow-up change will remove the actual JAR. One small step towards making the Bazel binary smaller :)
--
PiperOrigin-RevId: 141355143
MOS_MIGRATED_REVID=141355143
|
|
|
|
|
|
|
|
| |
(series 3/4 of open-sourcing coverage command for java test)
--
PiperOrigin-RevId: 141046146
MOS_MIGRATED_REVID=141046146
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
junitrunner/java/com/google/testing/junit/runner/sharding/weighted has an internal reference that is not easy to open-source. For now it makes more sense to roll this back and keep this package just internally.
*** Original change description ***
Open sourcing junitrunner/java/com/google/testing/junit/runner/sharding/weighted.
--
MOS_MIGRATED_REVID=138852305
|