| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I realized that I wrote the wrong warning code when I use Bazel from master branch and build something with MSVC.
For the curious:
- C4117: https://msdn.microsoft.com/en-us/library/9d2szxf8.aspx
- C4177: https://msdn.microsoft.com/en-us/library/s4becxs9.aspx
/cc @meteorcloudy
Closes #5631.
PiperOrigin-RevId: 207235606
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Remove `/D_SILENCE_STDEXT_HASH_DEPRECATION_WARNINGS`: it disables warnings for deprecated C++ headers (`<stdext/*>`, `<hash_map>` etc.). Only useful for legacy codebase.
- Remove `/J`: `char` is signed according to ISO C++. There is no reason to make `char` unsigned by default.
- Remove default `/Gy`: moved to feature (`smaller_binary`).
- Remove default `/GF`: string pooling, enabled by default with `/O2`.
- Remove `/DDEBUG` in `dbg` mode: conflict with macros defined in some OSS projects such as LLVM. User should use standard `NDEBUG` to detect debug mode.
Implements a few general `feature` to abstract away details about the compiler:
- `treat_warnings_as_errors`: aka `-Werror`.
- `frame_pointer`: aka `-fno-omit-frame-pointer'.
- `determinism`: redact `__TIME__` macros etc.
- `disable_assertions`: allow user to have `assert/DCHECK` back even in `opt` mode.
- `smaller_binary`: common optimization enabled in `opt` mode. Still allow user to disable it in `opt` (such as when using ASAN).
- `ignore_noisy_warnings`: suppress a bunch of warnings most people don't care. If users want to be pedantic, they can still get those warnings back with `--features=-ignore_noisy_warnings`.
Closes #5519.
PiperOrigin-RevId: 203959555
|
|
|
|
|
|
|
|
|
|
| |
This makes console output of `bazel build -s` shorter when debugging `CROSSTOOL`.
/cc @meteorcloudy
Closes #5539.
PiperOrigin-RevId: 203899866
|
|
|
|
|
|
|
|
|
|
| |
library
1. Do not apply /WHOLEARCHIVE to interface library
2. On Windows, we cannot link dll directly, so remove related flag_groups
RELNOTES: None
PiperOrigin-RevId: 203752406
|
|
|
|
|
|
|
|
|
|
|
| |
The only reason that those python wrapper scripts still exists is for
TensorFlow's Windows GPU build. As we will create a custom GPU CROSSTOOL
in TF repo, we can finally remove wrapper scripts from Bazel.
Closes #5526.
RELNOTES: Python wrapper scripts for MSVC are removed.
PiperOrigin-RevId: 203472223
|
|
|
|
|
|
|
| |
Should not be needed anymore since we have dynamic configurations for a while.
RELNOTES: None.
PiperOrigin-RevId: 203435557
|
|
|
|
|
|
|
| |
Fixed https://github.com/bazelbuild/bazel/issues/5495
RELNOTES: None
PiperOrigin-RevId: 202929359
|
|
|
|
|
|
|
| |
This was never used. We thought it will be useful, but it's not.
RELNOTES: None.
PiperOrigin-RevId: 202143524
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change makes Bazel respect artifact name patterns specified in
CROSSTOOL.
Users cannot specify any arbitrary name pattern, it must ends with allowed
extensions. For example, for dynamic library, it can only ends with .so,
.dylib or .dll, otherwise Bazel throws an error.
Change-Id: I21d9e6fa7c3a282e1a9b8ff29679b00925cddb33
PiperOrigin-RevId: 197553413
|
|
|
|
|
|
|
|
| |
The difference between them is that user_link_flags will stay after we remove
legacy fields from the crosstool.
RELNOTES: None.
PiperOrigin-RevId: 196940832
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 196870840
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 191713379
|
|
|
|
|
|
|
|
|
| |
The entries in BUILD.tpl specify cpu "local", so CROSSTOOL.tpl needs to match.
Closes #4957.
Change-Id: I68d7148fa6cb73cd83ef99eab76e0fd2f6227580
PiperOrigin-RevId: 191444915
|
|
|
|
|
|
|
|
|
| |
The proguard.txt is the concatenation of the proguard_specs on the android_library rule itself. Note that it does not include transitively defined proguard_specs.
Fixes https://github.com/bazelbuild/bazel/issues/4467
RELNOTES: android_library AAR output now contains proguard.txt
PiperOrigin-RevId: 191302610
|
|
|
|
| |
Change-Id: If9d641445dc8c6520b5f4c53eab438e44486b5ac
|
|
|
|
|
|
|
|
|
|
|
| |
We don't need to separate them into 4 different flavours, all crosstools define
them identically anyway.
RELNOTES: CppRules: Unified action_configs for static libraries
From now on only c++-link-static-library is read.
PiperOrigin-RevId: 188726352
|
|
|
|
|
|
|
|
| |
The previous comment referred to the option `/EHa`, but `/EHsc` is the option to only catch C++ standards (which seems to be what we want, according to this doc: https://msdn.microsoft.com/en-us/library/1deeycx5.aspx)
Closes #4739.
PiperOrigin-RevId: 187593737
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this cl toolchain author can specify different flags for linking shared
library produced by cc_library and a shared library produced by cc_binary.
This is what is needed to remove linking_mode_flags - MOSTLY_STATIC_LIBRARIES
from the crosstool. What this linking mode was used for was to separate when we
link transitive shared library from cc_binary and when we link this
little-and-not-really-useful-outside-of-bazel nodeps shared library in cc_library.
RELNOTES: CcToolchain: Introduced action_config for "c++-link-transitive-dynamic-library"
PiperOrigin-RevId: 187523334
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Rolling back after having come up with a more principled solution in b/73047818 that will add a more generic attribute called additional_linker_inputs so that users can depend on any file of any type and reference it from linkopts.
*** Original change description ***
C++: Allows adding linkopts through file.
The file can be generated during execution by a different rule.
RELNOTES:none
PiperOrigin-RevId: 185977745
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
*** 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
|
|
|
|
|
|
|
|
|
|
|
|
| |
If no_stripping feature is enabled, then strip action config is not
necessary, building stripped binary will just copy the orignial binary.
Fix https://github.com/bazelbuild/bazel/issues/3482
Also fixed CI breakage:
https://github.com/bazelbuild/bazel/issues/3505
Change-Id: Ie78fe174c42248c9b3e930008eef96dcd1864741
PiperOrigin-RevId: 164237588
|
|
|
|
|
|
|
|
|
|
|
| |
This cl changes copts to be immutable (and changes addCopts methods into
setCopts, so it's simpler to reason about copts) and exposes copts as a build
variable. It also introduces CompileBuildVariablesTest, similar to
LinkBuildVariablesTest, to test that right build variables are exposed for right
actions.
RELNOTES: None.
PiperOrigin-RevId: 163876774
|
|
|
|
|
|
|
| |
Fix https://github.com/bazelbuild/bazel/issues/3473
RELNOTES: None
PiperOrigin-RevId: 163686215
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 163679651
|
|
|
|
|
|
|
|
| |
Fix https://github.com/bazelbuild/bazel/issues/3474
Fix https://github.com/bazelbuild/bazel/issues/3472
RELNOTES: None
PiperOrigin-RevId: 163677371
|
|
|
|
|
|
|
|
|
| |
BUILD file. They must use "-" instead of "/"
otherwise Bazel believes the linkopts entry
declares a (invalid) label.
Change-Id: I6ad33c3f51c37f59e7d3b92be872fc4e2b27d434
PiperOrigin-RevId: 162597691
|
|
|
|
|
|
|
| |
Fixed https://github.com/bazelbuild/bazel/issues/3366
RELNOTES: None
PiperOrigin-RevId: 161926642
|
|
|
|
|
|
|
|
|
| |
/DNOMINMAX is a very common use and no one has complained about it yet, so keep it in CROSSTOOL
Fixed https://github.com/bazelbuild/bazel/issues/3347
RELNOTES: None.
PiperOrigin-RevId: 161381862
|