| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
The file can be generated during execution by a different rule.
RELNOTES:none
PiperOrigin-RevId: 185361140
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this cl CompileCommandLine would (almost) unconditionally emit -c and
-o flags. This cl removes this logic and relies on crosstool to emit these
flags. This is another small step towards platform independent C++ rules.
Memory use is not affected, since the build variables used by this cl are already
exposed, this cl just forces crosstools to use it.
Encore of https://github.com/bazelbuild/bazel/commit/f26e8694ae78599b3e2004e3360eaf3443fa53a6.
RELNOTES: None.
PiperOrigin-RevId: 184981106
|
|
|
|
|
|
|
|
|
|
|
|
| |
compiled as part of bazel's repository bootstrap. This should make crosstool's clang invocations faster. An added benefit of this is that wrapped_clang.cc supports the "DSYM_HINT" flags specified through the CROSSTOOL, so with this change, apple_binary gets support for the --apple_generate_dsym flag.
The dSYM generation issue has been flagged multiple times:
https://github.com/bazelbuild/bazel/issues/4312
https://github.com/bazelbuild/bazel/issues/3940
https://github.com/bazelbuild/bazel/issues/3372
RELNOTES: apple_binary can now generate dSYM outputs with the --apple_generate_dsym=true flag.
PiperOrigin-RevId: 184688215
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks C++ on gcc 4.8.4 (specifically, TensorFlow: https://github.com/bazelbuild/bazel/issues/4474)
Fixes #4474
*** Original change description ***
When linking mostly-static Linux binaries, link libstdc++.a explicitly.
This allows libstdc++ to be statically linked, which is normally only
possible when invoking GCC as `g++` with the `-static-libstdc++` flag.
Fixes https://github.com/bazelbuild/bazel/issues/2840
See https://github.com/envoyproxy/envoy/issues/415 for additional
background and context.
cc @htuch (for Envoy) and @calpeyser @hlopko (who I talked to earlier about this)...
***
RELNOTES: None.
PiperOrigin-RevId: 182519445
|
|
|
|
|
|
|
|
|
| |
The `+` operator on dicts is deprecated and will be removed. This change makes
Bazel files compatible with the new behavior.
Fixes #4346.
PiperOrigin-RevId: 180702882
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to have --cpu=x64_windows_msys for selecting msys gcc toolchain,
this is a misuse of --cpu flag.
Instead, we should use --compiler flag to select C++ toolchain.
For example, --compiler=msvc-cl, --compiler=msys-gcc, --compiler=mingw-gcc
After this change, we can use mingw gcc toolchain by following steps:
1. In MSYS, install mingw by `pacman -S mingw-w64-x86_64-gcc`
2. Add /mingw64:/mingw64/bin into PATH
3. build with --compiler=mingw-gcc
Related:
https://github.com/bazelbuild/rules_go/issues/736
Change-Id: I4b5f77ce0698cfcafefe5d2ab17657f9c9e295d3
PiperOrigin-RevId: 180678829
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bazel's autoconf script adds -fno-canonical-system-headers to gcc's crosstool
in order to get output in '.d' files that can be properly verified by bazel.
To workaround the same issue in clang we have to use a different flag:
'-no-canonical-prefixes'.
The same issue arises with clang if it resides in the configured repository
(e.g., when it is downloaded via 'repository_ctx.download').
PiperOrigin-RevId: 180552155
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Generated crosstool previously used absolute paths for everything.
However, when using a compiler, local to the repository (e.g., downloaded via
'repository_ctx.download'), relative paths should be used to avoid absolute
paths that point into the crosstool repository.
Specifically, this patch contains the following changes:
1. Replaces absolute paths in 'cxx_builtin_include' with relative if includes
point inside the repository.
2. Removes the '-B<compiler-dir>' from 'compiler_flag' and 'linker_flag'
sections when compiler is inside the repository.
PiperOrigin-RevId: 180540359
|
|
|
|
|
|
| |
cc_toolchain_type //tools/cpp:toolchain_type.
PiperOrigin-RevId: 179818065
|
|
|
|
|
|
| |
This makes sure the BUILD files we publish in https://github.com/bazelbuild/bazel-toolchains has the right license notice.
PiperOrigin-RevId: 179686473
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds a few extension points to cc_configure script with
the ultimate goal to allow downloading the compiler and other tools
used for C++ build before generating the crosstool.
Specifically, we make the following changes:
- Expose the implementation of a cc_autoconf repository rule under a
name of cc_autoconf_impl.
- Extend cc_autoconf_impl to allow overriding paths to build
tools (i.e. compilers, linkers, etc.)
- Allow to put any extra artifacts into the generated crosstool
repository. All files inside 'extra_tools' folder are added into
compiler_files, all_files and linker_files properties of the
generated crosstool, so that they are available for the crosstool.
With these extension one can do the following to download the
compilers used for the build and configure the crosstool:
- Create a repository_rule for the toolchain with a custom
implementation.
- In the implementation function of the repository rule:
+ Download the compilers and put them into `extra_tools` folder.
+ Run cc_autoconf_impl with overriden_tools set to relative paths
of the compiler and other build tools in the extra_tools folder.
Change-Id: I51af6b504578963b3e97bcdd1ccb6d0a5fed1c3e
PiperOrigin-RevId: 179675911
|
|
|
|
|
|
|
|
|
|
| |
After 8b3ba50246fed6ff13d70299fb039cc66be465c4, msys path should not
appear in CROSSTOOL, because Bazel won't translate it anymore.
Fix https://github.com/bazelbuild/bazel/issues/4318
Change-Id: I33d783a2ef14299e586856fefa2d68adce587045
PiperOrigin-RevId: 179667545
|
|
|
|
|
|
|
|
|
| |
https://github.com/bazelbuild/bazel/commit/2aeaeba66857c561dd6d63c79a213f1cabc3650d
Fixes #4288
RELNOTES: None.
PiperOrigin-RevId: 178889458
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows libstdc++ to be statically linked, which is normally only
possible when invoking GCC as `g++` with the `-static-libstdc++` flag.
Fixes https://github.com/bazelbuild/bazel/issues/2840
See https://github.com/envoyproxy/envoy/issues/415 for additional
background and context.
cc @htuch (for Envoy) and @calpeyser @hlopko (who I talked to earlier about this)
I'm only doing this in the Linux toolchain because MacOS doesn't do static linking of system libs anyway, and I don't know enough about Windows or FreeBSD to test on those platforms.
Closes #4031.
PiperOrigin-RevId: 178762357
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 178745230
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is set to "1"
By default when xcode is installed on darwin bazel will pick a toolchain that
supports both C++ and ObjC. This cl allows the user to pick C++ only
toolchain even when Xcode is installed.
Fixes #4231.
RELNOTES: None.
PiperOrigin-RevId: 178745218
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
support it
This makes Bazel work nicer with VC++ version prior to VC++ 2015, but it
doesn't mean we fully support them. For example, /WHOLEARCHIVE doesn't
work with versions older that VC++ 2015, either.
Fixed https://github.com/bazelbuild/bazel/issues/3109
Fixed https://github.com/bazelbuild/bazel/issues/4240
Change-Id: Iab7280bea241a203cb04dc9ca0a7b3bce518fb64
PiperOrigin-RevId: 178615516
|
|
|
|
|
|
|
|
|
|
|
| |
Bazel's fallback action config for PGO optimization uses Google-internal
compiler flags. Here, we provide a 'fdo_optimize' feature without these internal
flags, so --fdo_optimize can work out of the box.
This fixes https://github.com/bazelbuild/bazel/issues/1171.
Change-Id: I1d40eb72211e7c5bea213de7d2c237ac2877b3a1
PiperOrigin-RevId: 177947264
|
|
|
|
|
|
|
|
| |
the CppConfiguration Skylark API to migrate to platforms and toolchains.
For more details on toolchains, please see https://docs.google.com/document/d/1-G-VPRLEj9VyfC6VrQBiR8To-dZjnBSQS66Y4nargGM/edit#heading=h.al54v2ddwqzv
PiperOrigin-RevId: 177811908
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
find_vc_path and find_msvc_tool are now visible from
windows_cc_configure.bzl, users can do:
load("@bazel_tools//tools/cpp:windows_cc_configure.bzl",
"find_vc_path"
"find_msvc_tool")
to get Visual C++ path and find Visual C++ tools detected
by Bazel in their repository rule.
Change-Id: Ifb6d1f412e64251f413a59d3149d44ca2f8bc5d7
PiperOrigin-RevId: 177589321
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 176646230
|
|
|
|
|
|
|
| |
Fixed https://github.com/bazelbuild/bazel/issues/4144
RELNOTES: None
PiperOrigin-RevId: 176642833
|
|
|
|
| |
PiperOrigin-RevId: 176510846
|
|
|
|
|
|
|
|
|
|
|
| |
Allows .asm files to be included in srcs. ml64.exe is used to create .o files which can later be linked. However, this change will not allow custom flags to be passed to ml64.exe other than /I and /D.
Fixes #3648
Closes #3887.
Change-Id: I42b6ff76d526abed440bb7f0e0ed4cc3812b4893
PiperOrigin-RevId: 176085382
|
|
|
|
|
|
|
|
| |
The wrapper script is now only necessary for TensorFlow GPU build.
Since the link option for MSVCRT is controlled by CROSSTOOL, we should remove the hack in wrapper script to avoid conflict.
RELNOTES: None
PiperOrigin-RevId: 175664202
|
|
|
|
|
|
|
|
| |
RELNOTES[NEW]: Users can use win_def_file attribute to specify a DEF file for
exporting symbols when build a shared library on Windows.
Change-Id: Ifa28d8b7b24eaefcefc9640d8dc56fd2931e9688
PiperOrigin-RevId: 175651203
|
|
|
|
|
|
| |
//tools/cpp:toolchain_type as the canonical c++ toolchain.
PiperOrigin-RevId: 174759558
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When Visual C++ build tools are not found on Windows, we generating a
fake CROSSTOOL so that users can still build for other languages.
In the fake CROSSTOOL, we point all tools to a batch script which prints
error messages to notify users when they try to build any cc targets.
Also, added an extra default_toolchain specification for x64_windows cpu
value, so that users can use this cpu in select on non-Windows
platforms.
Fixed https://github.com/bazelbuild/bazel/issues/3853
Change-Id: Ib4d7a38fd4d98075f6b73ce310c28822e58af4e2
PiperOrigin-RevId: 172341985
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In https://github.com/bazelbuild/bazel/commit/f426544e67170d31b9d228ecf4cdc4b6ce1ba00d I updated osx_cc_wrapper to work correctly in case both
precompiled .so and cc_library-made .so are linked into a single binary. This cl
makes osx_cc_wrapper work also when a precompiled .dylib is provided.
This is roll-forward of https://github.com/bazelbuild/bazel/commit/0257c29f496719bb8414d012334155de6bbefa11.
Fixes #3450 again for dylibs
Fixes #407
One step closer to finishing #1576
RELNOTES: None.
PiperOrigin-RevId: 171969333
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
I broke http://ci.bazel.io/view/Dashboard/job/bazel-tests/1079/testReport/junit/(root)/(empty)/test_osx_cc_wrapper_rpaths_handling/
*** Original change description ***
Fix osx_cc_wrapper to also update dylibs
In https://github.com/bazelbuild/bazel/commit/f426544e67170d31b9d228ecf4cdc4b6ce1ba00d I updated osx_cc_wrapper to work correctly in case both
precompiled .so and cc_library-made .so are linked into a single binary. This cl
makes osx_cc_wrapper work also when a precompiled .dylib is provided.
Fixes #3450 again for dylibs
Fixes #407
One step closer to finishing #1576
RELNOTES: None.
PiperOrigin-RevId: 171806769
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In https://github.com/bazelbuild/bazel/commit/f426544e67170d31b9d228ecf4cdc4b6ce1ba00d I updated osx_cc_wrapper to work correctly in case both
precompiled .so and cc_library-made .so are linked into a single binary. This cl
makes osx_cc_wrapper work also when a precompiled .dylib is provided.
Fixes #3450 again for dylibs
Fixes #407
One step closer to finishing #1576
RELNOTES: None.
PiperOrigin-RevId: 171683650
|
|
|
|
|
|
|
|
|
| |
interface_library_output_path flag set
We shouldn't apply this flag set to c++-link-executable action, it will only add a /IMPLIB:ignore option.
RELNOTES: None.
PiperOrigin-RevId: 170459781
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is to replace using USE_DYNAMIC_CRT env variable to configure
msvcrt linking in CROSSTOOL.
If user applies static_link_msvcrt feature to a specific target,
Bazel will choose the correct options for statically linking msvcrt.
If static_link_msvcrt is not specified, Bazel uses options for dynamically linking
msvcrt by default.
https://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx
Change-Id: Ia078dfb528de9ffdd8a11d392db9eb3f34463b09
PiperOrigin-RevId: 170021927
|
|
|
|
|
|
|
|
|
|
|
| |
When copy_dynamic_libraries_to_binary is enabled, we copy the shared
libraries required by the binary to the binary's directory.
Bazel will throw errors if there are confilct actions generating the
same artifacts.
Change-Id: I09a5a599ca0ec7a67efd49d5aa89481450fa4e90
PiperOrigin-RevId: 169364498
|
|
|
|
| |
PiperOrigin-RevId: 168835640
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks clang_tidy.
*** Original change description ***
Introduce -c source_file -o output_file build variables
Prior to this cl CompileCommandLine would (almost) unconditionally emit -c and
-o flags. This cl removes this logic and relies on crosstool to emit these
flags. This is another small step towards platform independent C++ rules.
Memory use is not affected, since the build variables used by this cl are already
exposed, this cl just forces crosstools to use it.
RELNOTES: None.
PiperOrigin-RevId: 168834576
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this cl CompileCommandLine would (almost) unconditionally emit -c and
-o flags. This cl removes this logic and relies on crosstool to emit these
flags. This is another small step towards platform independent C++ rules.
Memory use is not affected, since the build variables used by this cl are already
exposed, this cl just forces crosstools to use it.
RELNOTES: None.
PiperOrigin-RevId: 168671507
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
This cl removes hardcoded --sysroot flag generation from bazel when constructing
command line for C++ actions. The hardcoded flag is still exposed to Skylark (to
stay backwards compatible).
RELNOTES: None.
PiperOrigin-RevId: 168346711
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
user_compile_flags
Also add magic to a feature named 'unfiltered_compile_flags' so the flags
expanded from it are not subject to nocopt filtering.
This is encore of https://github.com/bazelbuild/bazel/commit/268c0bcbf79f9f3f72d95fa51af0f1b18c5ce29e that was rolled back because it regressed
memory.
RELNOTES: None.
PiperOrigin-RevId: 167989075
|
|
|
|
|
|
|
|
| |
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 ***
Rollback since this change is based on https://github.com/bazelbuild/bazel/commit/268c0bcbf79f9f3f72d95fa51af0f1b18c5ce29e, which is rollbacked due to a performance reason
RELNOTES: None.
PiperOrigin-RevId: 167836715
|
|
|
|
|
|
|
|
|
| |
https://github.com/bazelbuild/bazel/commit/268c0bcbf79f9f3f72d95fa51af0f1b18c5ce29e
Fixes #3693
RELNOTES: None.
PiperOrigin-RevId: 167704700
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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
|