aboutsummaryrefslogtreecommitdiffhomepage
path: root/tools/BUILD
Commit message (Collapse)AuthorAge
* Automated rollback of commit 8a5a0a3ed1e19768b6ee024189307bb4ac27460d.Gravatar laszlocsomor2018-03-21
| | | | | | | | | | | | | | | | | | | | | | | | | *** 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
* runfiles,C++: move to //tools/cpp/runfilesGravatar Laszlo Csomor2018-03-21
| | | | | | | | | | | | | | | | | | 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
* runfiles,Bash: add a package for runfiles libraryGravatar Laszlo Csomor2018-03-21
| | | | | | | | | | | Add a new package that'll host the Bash runfiles library. See https://github.com/bazelbuild/bazel/issues/4460 Closes #4882. PiperOrigin-RevId: 189871255
* java,runfiles: runfiles library in @bazel_toolsGravatar Laszlo Csomor2018-01-16
| | | | | | | | | | | | | | 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
* Bazel now can build dynamic library from cc_libraryGravatar Yun Peng2017-09-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Automated rollback of commit ca216f5eb4b1f1892219db0f578495bbbdbaa875.Gravatar philwo2017-09-15
| | | | | | | | | | | | | | | *** 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
* Remove docker rules from @bazel_toolsGravatar Googler2017-09-14
| | | | | | | | | ... 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
* Introduce empty "toolchain_category" rule for labels that will be used asGravatar cpeyser2017-09-14
| | | | | | | | 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
* Add a new toolchain type for c++. In order to do this, ↵Gravatar cpeyser2017-09-08
| | | | | | | | 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
* Automated rollback of commit 2b983bdf508e010a3d4ee9dbaf446b7666749799.Gravatar cpeyser2017-09-01
| | | | | | | | | | | | *** 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
* Rollforward of c++ toolchain-relevant BUILD file and Bazel mocking changes. ↵Gravatar cpeyser2017-08-31
| | | | | | That is, a c++ toolchain is added, but a Bazel dependency on that toolchain is not. PiperOrigin-RevId: 167006332
* Automated rollback of commit 9d5bce66280094c0531ddfde2752e596d0d78c79.Gravatar plf2017-08-30
| | | | PiperOrigin-RevId: 166966182
* Add a new toolchain type for c++. In order to do this, ↵Gravatar cpeyser2017-08-29
| | | | | | | | 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
* Automated rollback of commit 363413110f3a63a11d900864be1852adbaed2899.Gravatar cpeyser2017-08-29
| | | | | | | | | | | | | | | | | | | | | | | | | | *** 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
* Add a new toolchain type for c++. In order to do this, ↵Gravatar cpeyser2017-08-28
| | | | | | | | 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
* Remove FeaturePolicyConfiguration et al. in favor of the new Whitelisting.Gravatar mstaib2017-08-22
| | | | | | | | 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
* Remove old intellij aspect code bundled with BazelGravatar Googler2017-07-31
| | | | PiperOrigin-RevId: 163538636
* Apply native binary launcher to sh_binaryGravatar Yun Peng2017-07-31
| | | | | | | | | | | | 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
* Add missing dependency.Gravatar Googler2017-04-20
| | | | PiperOrigin-RevId: 153584278
* Move the sha256 tool into its own directory, as it isn't specific to ↵Gravatar Googler2017-04-19
| | | | | | docker_build. PiperOrigin-RevId: 153508081
* Remove jack tools from Bazel.Gravatar ajmichael2017-04-05
| | | | | | | | #1391 RELNOTES: None PiperOrigin-RevId: 152179305
* Add default constraint_settings and values in new package ↵Gravatar John Cater2017-03-23
| | | | | | | | | | | | @bazel_tools//platforms. Part of #2219. -- Change-Id: I312c70e0c9064cbf4c4346a59bff04ada92e4890 Reviewed-on: https://cr.bazel.build/9412 PiperOrigin-RevId: 151016060 MOS_MIGRATED_REVID=151016060
* Delete //external references related to protos.Gravatar Carmi Grushko2017-02-03
| | | | | | | | These are not used anymore. -- PiperOrigin-RevId: 146381129 MOS_MIGRATED_REVID=146381129
* Don't bundle android tests into the Bazel binary.Gravatar Adam Michael2017-01-20
| | | | | | | | Saves 12kB! :) -- PiperOrigin-RevId: 144997917 MOS_MIGRATED_REVID=144997917
* Coverage support.Gravatar Ulf Adams2016-11-24
| | | | | | | | | | | | | | | | | - 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
* Move intellij_info.bzl to a tool packaged with bazel.Gravatar Googler2016-11-21
| | | | | | | | This will allow use of the Skylark IDE aspect in bazel, unblocking the migration away from the native aspect. -- MOS_MIGRATED_REVID=139796095
* Use proto_lang_toolchain in java_lite_proto_library.Gravatar Carmi Grushko2016-11-03
| | | | | -- MOS_MIGRATED_REVID=138005602
* Add Skylark definitions of {new_,}git_repository.Gravatar Nelson Elhage2016-07-27
| | | | | | | -- Change-Id: I2c5f09b10430963a1668ec7c842992bc89bfd7b4 Reviewed-on: https://bazel-review.googlesource.com/#/c/3982 MOS_MIGRATED_REVID=128453417
* Export xcode_locator's source file under tools/osx/ to make it available for ↵Gravatar Chris Parsons2016-07-21
| | | | | | | 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
* Add all the sources to //:srcs filegroup and add a check to detectGravatar Damien Martin-Guillerez2016-07-01
| | | | | | | | | | | 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
* Remove rust, jsonnet, scala and closure from the Bazel repositoryGravatar Damien Martin-Guillerez2016-05-09
| | | | | | | | 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
* Add a Skylark rule to build Swift modules.Gravatar Dmitry Shevchenko2016-04-22
| | | | | | | | * 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
* Remove te protocol compiler rules from @bazel_tools.Gravatar Lukacs Berki2016-04-11
| | | | | | | | | | | | 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
* Remove deprecated Skylark rulesGravatar Kristina Chodorow2016-03-24
| | | | | -- MOS_MIGRATED_REVID=117968196
* Add missing filegroups to the srcsGravatar Damien Martin-Guillerez2016-03-18
| | | | | -- MOS_MIGRATED_REVID=117534962
* Move dump_syms from //tools/objc to //tools/osx. This will allow it to be ↵Gravatar Cal Peyser2016-03-15
| | | | | | | referenced from the crosstool without crossing package boundaries. -- MOS_MIGRATED_REVID=117137594
* Add a bazel-srcs target to the top-level package containing all Bazel sourcesGravatar Damien Martin-Guillerez2016-02-29
| | | | | | | | This target include all non tests targets of Bazel to do integration tests of bootstrapping. -- MOS_MIGRATED_REVID=115830741
* Turn //tools/build_rules into a package.Gravatar Julio Merino2016-02-17
| | | | | | | | | 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
* Stop bundling ijar's sources in bazel_toolsGravatar Damien Martin-Guillerez2016-02-17
| | | | | | | | | | 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
* Add Android targets back into embedded toolsGravatar Kristina Chodorow2016-01-28
| | | | | | | Accidentally removed in the previous change to this file. -- MOS_MIGRATED_REVID=113170839
* Add pkg and various other skylark rules to the embedded toolsGravatar Damien Martin-Guillerez2016-01-27
| | | | | | | | 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
* Source iOS memleak plugin stub from bazel_tools.Gravatar Peter Schmitt2015-12-16
| | | | | -- MOS_MIGRATED_REVID=110280939
* Add srcs for Go rules.Gravatar Han-Wen Nienhuys2015-11-17
| | | | | -- MOS_MIGRATED_REVID=107939664
* Include memleaks plugin support for experimental_ios_testGravatar Chris Parsons2015-10-21
| | | | | -- MOS_MIGRATED_REVID=105876178
* Introduce debian and tar packaging rulesGravatar Damien Martin-Guillerez2015-10-09
| | | | | | | | | | | 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
* Embed a tools directory into the Bazel binary.Gravatar Lukacs Berki2015-10-06
| | | | | | | 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
* Initial checkin of sass_binary support for bazelGravatar Derek Perez2015-09-24
| | | | | | | | | RELNOTES[NEW]: Support for build with libsass. -- Change-Id: I2a24212d9466e2e2a8b653027f1cc9579b4d4221 Reviewed-on: https://bazel-review.googlesource.com/#/c/1990/ MOS_MIGRATED_REVID=103740130
* Add Jsonnet rules to Bazel.Gravatar David Chen2015-09-14
| | | | | | | RELNOTES: Add Jsonnet rules to Bazel -- MOS_MIGRATED_REVID=102895524
* Fix the installer and fixing the package shiped into binary version of Bazel.Gravatar Damien Martin-Guillerez2015-09-08
| | | | | -- MOS_MIGRATED_REVID=102567966
* Add missing tools directory in the filegroup to packageGravatar Damien Martin-Guillerez2015-09-03
| | | | | | | A lot of build rules weren't shiped in the Bazel binary because of those missing filegroups -- MOS_MIGRATED_REVID=102223626
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-03 23:58:02 +0000