aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/create_embedded_tools.py
Commit message (Collapse)AuthorAge
* Do not create empty tools/defaults/BUILD file.Gravatar dbabkin2018-08-14
| | | | | | | Cleaning up all references to in-memory tools/defaults:* package. RELNOTES:none PiperOrigin-RevId: 208610485
* Enable android dependency checking in Bazel.Gravatar xingao2018-06-29
| | | | | RELNOTES: None. PiperOrigin-RevId: 202644613
* Fix missing singlejar on arm and windowsGravatar Pascal Terjan2018-03-05
| | | | | | | | This was broken by the jar being renamed from SingleJar_deploy.jar to bazel-singlejar_deploy.jar in commit 6705b508fe069147c853ca9669363342f3527689 (Fixes #3988) Closes #4642. PiperOrigin-RevId: 187880736
* python,runfiles: runfiles library in @bazel_toolsGravatar Laszlo Csomor2018-02-05
| | | | | | | | | | | | | Also update the Python stub script template to set $RUNFILES_MANIFEST_FILE or $RUNFILES_DIR so the runfiles library only needs to look for those. See https://github.com/bazelbuild/bazel/issues/4460 RELNOTES[NEW]: python,runfiles: You can now depend on `@bazel_tools//tools/runfiles:py-runfiles` to get a platform-independent runfiles library for Python. See DocString of https://github.com/bazelbuild/bazel/blob/master/src/tools/runfiles/runfiles.py for usage information. Change-Id: I4f68a11cb59f2782e5203e39fe60cc66b46023a2 PiperOrigin-RevId: 184515490
* Partially revert fca3d391161ae4c92cf289a897db2a1c69a9b334Gravatar Klaus Aehlig2018-01-19
| | | | | | | ...as it breaks shell tests Change-Id: I191ec7c0f36832ff064af0b756a8c8fb41eb2a87 PiperOrigin-RevId: 182509548
* Create function createJavaInfo with new API. Implement JavaExportsProvider.Gravatar dbabkin2018-01-18
| | | | | | | | | | | | Added tests for checking JavaExportsProvider state. Refactored logic working with collection in favor of using Streams to improve readability. All other providers will be implemented in next CLs. previous CL with JavaCompilationArgsProvider implementation is https://github.com/bazelbuild/bazel/commit/32dff21d00ad7d1bdf50e8761d675a6e7e002de9, JavaSourceJarsProvider : https://github.com/bazelbuild/bazel/commit/5bd53cb609480ca896ca2d011f415b424c63ce63 RELNOTES:none PiperOrigin-RevId: 182342490
* Update javac version to 9+181-r4173-1Gravatar Liam Miller-Cushon2018-01-18
| | | | Change-Id: I05fa85967317c4581081adfc620e24a7c6322669
* 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
* 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
* 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
* Update javac version to 9-dev-r4023-3Gravatar Liam Miller-Cushon2017-08-22
| | | | | Change-Id: If9373f81193050009432759da6299f1382e587ec PiperOrigin-RevId: 165994437
* Extract a library from create_embedded_tools.pyGravatar László Csomor2017-08-11
| | | | | | | | | We'll use the extracted functions in the upcoming Python-based reincarnation of the //:bazel-distfile rule. Change-Id: I5140938ae4af50f62fb695b5b96cd41f3cd939ef PiperOrigin-RevId: 164950515
* Make create_embedded_tools.py python 2.6 friendlyGravatar hlopko2017-08-09
| | | | | | | | Centos 6.7 provides only python 2.6. And since we test bazel with this version, let's replace the only python 2.7 use with the python 2.6 friendly code. RELNOTES: None. PiperOrigin-RevId: 164704194
* Replace create_embedded_tools.sh with a faster Python version.Gravatar Philipp Wollermann2017-07-28
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
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-17 11:44:21 +0000