| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
https://github.com/bazelbuild/bazel/commit/819bf38d97e6eef3c823bdae3ffcdb013d6d83e3.
RELNOTES: none
PiperOrigin-RevId: 194770938
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the half-done C++ runfiles library to
`//tools/cpp/runfiles`. (The Python and
Bash runfiles libraries are already under
`//tools/<language>/runfiles`.)
See https://github.com/bazelbuild/bazel/issues/4460
Change-Id: I1006f7f81462ea0e4b1de1adcdba89e386d4f9e7
Closes #5107.
Change-Id: I1006f7f81462ea0e4b1de1adcdba89e386d4f9e7
PiperOrigin-RevId: 194763392
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bazel automatically detects the local Bash and
creates a custom toolchain rule for it.
Later, rules that use Bash will require this
toolchain and retrieve Bash's path from it instead
of relying on hardcoded paths or the
`--shell_executable` flag.
See https://github.com/bazelbuild/bazel/issues/4319
Change-Id: Idd8242a20d202b1f5a56cddac95b625c6c08ede9
Closes #4980.
Change-Id: Ic2406a4da260b284e15852070d58472ca18340af
PiperOrigin-RevId: 193022708
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the Python runfiles library from
`@bazel_tools//tools/runfiles:py-runfiles` to
`@bazel_tools//tools/python/runfiles:runfiles`
Also rename the testdata runfiles.py to foo.py.
This file was not a mock runfiles library, just a
client file using the runfiles library that was
also called runfiles.py
Fixes https://github.com/bazelbuild/bazel/issues/4878
Change-Id: I874b230c93679d4454ac91e816932c8272ecc5c7
Closes #4981.
Change-Id: I908e0ab7ec61225e82f70793b1a05432e7f0b07e
PiperOrigin-RevId: 192256481
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
breaks building //src:bazel
*** Original change description ***
runfiles,C++: move to //tools/cpp/runfiles
Move the C++ runfiles library to the location of
the rest of the C++ tools.
Also change the C++ namespace to reflect the
directory hierarchy.
We have not yet announced nor released the C++
runfiles library so these refactorings are fine.
See https://github.com/bazelbuild/bazel/issues/4460
Closes #4873.
PiperOrigin-RevId: 189883066
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the C++ runfiles library to the location of
the rest of the C++ tools.
Also change the C++ namespace to reflect the
directory hierarchy.
We have not yet announced nor released the C++
runfiles library so these refactorings are fine.
See https://github.com/bazelbuild/bazel/issues/4460
Closes #4873.
Change-Id: I1732ef1eaff880cae05b7d218a3b1c0461a6b029
PiperOrigin-RevId: 189874201
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new package that'll host the Bash runfiles
library.
See https://github.com/bazelbuild/bazel/issues/4460
Closes #4882.
PiperOrigin-RevId: 189871255
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
... 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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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
|
|
|
|
|
|
| |
That is, a c++ toolchain is added, but a Bazel dependency on that toolchain is not.
PiperOrigin-RevId: 167006332
|
|
|
|
| |
PiperOrigin-RevId: 166966182
|
|
|
|
|
|
|
|
| |
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: 166854893
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks //src/test/shell/bazel:bazel_bootstrap_distfile_test:
INFO: You can skip this first step by providing a path to the bazel binary as second argument:
INFO: ./compile.sh compile /path/to/bazel
🍃 Building Bazel from scratch......
🍃 Building Bazel with Bazel.
.WARNING: /tmp/bazel_cHivhPBc/out/external/bazel_tools/WORKSPACE:1: Workspace name in /tmp/bazel_cHivhPBc/out/external/bazel_tools/WORKSPACE (@io_bazel) does not match the name given in the repository's definition (@bazel_tools); this will cause a build error in future versions.
ERROR: in target '//external:cc_toolchain': error loading package '@local_config_cc//': Extension file not found. Unable to load file '@local_config_cc//:dummy_toolchain.bzl': file doesn't exist or isn't a file.
INFO: Elapsed time: 3.343s
ERROR: Could not build Bazel
Found by git bisect.
*** Original change description ***
Add a new toolchain type for c++. In order to do this, 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: 166750885
|
|
|
|
|
|
|
|
| |
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: 166509298
|
|
|
|
|
|
|
|
| |
This migrates the config_feature_flag implementation over and removes the
old flag (which was not used except to test it). Fare thee well, old flag.
RELNOTES: None.
PiperOrigin-RevId: 165995681
|
|
|
|
| |
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
|
|
|
|
| |
PiperOrigin-RevId: 153584278
|
|
|
|
|
|
| |
docker_build.
PiperOrigin-RevId: 153508081
|
|
|
|
|
|
|
|
| |
#1391
RELNOTES: None
PiperOrigin-RevId: 152179305
|
|
|
|
|
|
|
|
|
|
|
|
| |
@bazel_tools//platforms.
Part of #2219.
--
Change-Id: I312c70e0c9064cbf4c4346a59bff04ada92e4890
Reviewed-on: https://cr.bazel.build/9412
PiperOrigin-RevId: 151016060
MOS_MIGRATED_REVID=151016060
|
|
|
|
|
|
|
|
| |
These are not used anymore.
--
PiperOrigin-RevId: 146381129
MOS_MIGRATED_REVID=146381129
|
|
|
|
|
|
|
|
| |
Saves 12kB! :)
--
PiperOrigin-RevId: 144997917
MOS_MIGRATED_REVID=144997917
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- open source CoverageCommand.java
- add a collect-coverage.sh script
- update test-setup.sh to be compatible with the coverage collector
- update StandaloneTestStrategy to provide the necessary env variables
- update StandaloneTestStrategy to set the right command line for coverage
- add support for C++ coverage
An HTML report can then be generated with genhtml like this:
genhtml -o report/ -p "$(readlink -f bazel-<project>)" path/to/coverage.dat
Progress on #1118.
--
MOS_MIGRATED_REVID=140125715
|
|
|
|
|
|
|
|
| |
This will allow use of the Skylark IDE aspect in bazel,
unblocking the migration away from the native aspect.
--
MOS_MIGRATED_REVID=139796095
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=138005602
|
|
|
|
|
|
|
| |
--
Change-Id: I2c5f09b10430963a1668ec7c842992bc89bfd7b4
Reviewed-on: https://bazel-review.googlesource.com/#/c/3982
MOS_MIGRATED_REVID=128453417
|
|
|
|
|
|
|
| |
reference by future repository rules. Removes the xcode-locator binary file under tools/objc. Originally, the precompiled binary was going to be referenced, but it's easier to build from source in the repository rule.
--
MOS_MIGRATED_REVID=128063694
|
|
|
|
|
|
|
|
|
|
|
| |
missing file to it.
We need to activate this check on presubmits
--
Change-Id: Ia95e92d3816ce92bb69bc0e2cf56e9c60b68d970
Reviewed-on: https://bazel-review.googlesource.com/#/c/3949/
MOS_MIGRATED_REVID=126404792
|
|
|
|
|
|
|
|
| |
Those rules were moved to, respectively, https://github.com/bazelbuild/rules_rust,
https://github.com/bazelbuild/rules_jsonnet, https://github.com/bazelbuild/rules_scala, and https://github.com/bazelbuild/rules_closure.
--
MOS_MIGRATED_REVID=121834063
|
|
|
|
|
|
|
|
| |
* Adds a swift_library rule that produces a (.a, .swiftmodule) pair. It can handle dependencies between modules and can be used as a dependency of objc_binary.
* Does not work with Objective-C yet.
--
MOS_MIGRATED_REVID=120578875
|
|
|
|
|
|
|
|
|
|
|
|
| |
The immmediate reason for this change is that we also need to add gRPC support to the proto rules, and we don't want to also support gRPC in a half-baked way.
This makes the Bazel binary much smaller and avoid giving false signals that we (for now) support protobuf compilation. The protobuf rules are only for compiling Bazel itself.
RELNOTES[INC]: Bazel does not embed protocol buffer-related rules anymore.
--
MOS_MIGRATED_REVID=119516246
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=117968196
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=117534962
|
|
|
|
|
|
|
| |
referenced from the crosstool without crossing package boundaries.
--
MOS_MIGRATED_REVID=117137594
|
|
|
|
|
|
|
|
| |
This target include all non tests targets of Bazel to do integration tests of
bootstrapping.
--
MOS_MIGRATED_REVID=115830741
|
|
|
|
|
|
|
|
|
| |
This is in preparation for another change that will add a new helper script
to the tools/build_rules directory, and such script requires a BUILD rule
of its own.
--
MOS_MIGRATED_REVID=114898083
|
|
|
|
|
|
|
|
|
|
| |
Instead bundle ijar's zipper binary so the skylark rules that depends on it
can use it from @bazel_tools.
A commit introducing windows config settings broke our appengine tutorial.
--
MOS_MIGRATED_REVID=114857080
|
|
|
|
|
|
|
| |
Accidentally removed in the previous change to this file.
--
MOS_MIGRATED_REVID=113170839
|
|
|
|
|
|
|
|
| |
We should delete the package-srcs filegroup at some point and just use the same for both
but we are about to remove the package-srcs so let just make this change for now.
--
MOS_MIGRATED_REVID=113163035
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=110280939
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=107939664
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=105876178
|
|
|
|
|
|
|
|
|
|
|
| |
This refactor a bit the docker rules to reuse the tarball construction.
Also introduce the debian archive for the release process.
RELNOTES[NEW]: Debian and tar packaging is now supported
(see tools/build_defs/pkg/README.md).
--
MOS_MIGRATED_REVID=105053604
|
|
|
|
|
|
|
| |
This is currently unused deadweight, but will be used pretty soon to access the tools directory instead the menagerie of various odd mechanism we currently use.
--
MOS_MIGRATED_REVID=104737151
|