maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/utils/bazel/.bazelrc

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

197 lines
9.8 KiB
Plaintext
Raw Normal View History

Introduce a Bazel build configuration This patch introduces configuration for a Bazel BUILD in a side directory in the monorepo. This is following the approval of https://github.com/llvm/llvm-www/blob/main/proposals/LP0002-BazelBuildConfiguration.md As detailed in the README, the Bazel BUILD is not supported by the community in general, and is maintained only by interested parties. It follows the requirements of the LLVM peripheral tier: https://llvm.org/docs/SupportPolicy.html#peripheral-tier. This is largely copied from https://github.com/google/llvm-bazel, with a few filepath tweaks and the addition of the README. Reviewed By: echristo, keith, dblaikie, kuhar Differential Revision: https://reviews.llvm.org/D90352
2021-05-19 06:42:25 +08:00
# This file is licensed under the Apache License v2.0 with LLVM Exceptions.
# See https://llvm.org/LICENSE.txt for license information.
# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
###############################################################################
# Common flags that apply to all configurations.
# Use sparingly for things common to all compilers and platforms.
###############################################################################
# Prevent invalid caching if input files are modified during a build.
build --experimental_guard_against_concurrent_changes
###############################################################################
# Options to select different strategies for linking potential dependent
# libraries. The default leaves it disabled.
###############################################################################
build:zlib_external --repo_env=BAZEL_LLVM_ZLIB_STRATEGY=external
build:zlib_system --repo_env=BAZEL_LLVM_ZLIB_STRATEGY=system
build:terminfo_external --repo_env=BAZEL_LLVM_TERMINFO_STRATEGY=external
build:terminfo_system --repo_env=BAZEL_LLVM_TERMINFO_STRATEGY=system
###############################################################################
# Options for "generic_clang" builds: these options should generally apply to
# builds using a Clang-based compiler, and default to the `clang` executable on
# the `PATH`. While these are provided for convenience and may serve as a
# reference, it would be preferable for users to configure an explicit C++
# toolchain instead of relying on `.bazelrc` files.
###############################################################################
# Set the default compiler to the `clang` binary on the `PATH`.
build:generic_clang --repo_env=CC=clang
# C++14 standard version is required.
build:generic_clang --cxxopt=-std=c++14 --host_cxxopt=-std=c++14
[Bazel] Don't fail the build on usage of deprecated APIs Build failures are not a particularly helpful way to enforce not using deprecated APIs and that isn't the point of the Bazel build. At the same time, this removes `-Wno-unused` this is a check that we do enforce in the Google internal build and so are ok maintaining in our maintenance of the upstream Bazel build (the comment about not wanting to do so was from a time when this was in a separate repository and I was the only one maintaining it). Differential Revision: https://reviews.llvm.org/D118671
2022-02-01 09:50:59 +08:00
# Use `-Wall` and `-Werror` for Clang.
build:generic_clang --copt=-Wall --copt=-Werror --host_copt=-Wall --host_copt=-Werror
Introduce a Bazel build configuration This patch introduces configuration for a Bazel BUILD in a side directory in the monorepo. This is following the approval of https://github.com/llvm/llvm-www/blob/main/proposals/LP0002-BazelBuildConfiguration.md As detailed in the README, the Bazel BUILD is not supported by the community in general, and is maintained only by interested parties. It follows the requirements of the LLVM peripheral tier: https://llvm.org/docs/SupportPolicy.html#peripheral-tier. This is largely copied from https://github.com/google/llvm-bazel, with a few filepath tweaks and the addition of the README. Reviewed By: echristo, keith, dblaikie, kuhar Differential Revision: https://reviews.llvm.org/D90352
2021-05-19 06:42:25 +08:00
# The Clang available on MacOS has a warning that isn't clean on MLIR code. The
# warning doesn't show up with more recent Clangs, so just disable for now.
build:generic_clang --cxxopt=-Wno-range-loop-analysis --host_cxxopt=-Wno-range-loop-analysis
[Bazel] Don't fail the build on usage of deprecated APIs Build failures are not a particularly helpful way to enforce not using deprecated APIs and that isn't the point of the Bazel build. At the same time, this removes `-Wno-unused` this is a check that we do enforce in the Google internal build and so are ok maintaining in our maintenance of the upstream Bazel build (the comment about not wanting to do so was from a time when this was in a separate repository and I was the only one maintaining it). Differential Revision: https://reviews.llvm.org/D118671
2022-02-01 09:50:59 +08:00
# Build errors are not a helpful way to enforce deprecation in-repo and it is
# not the point of the Bazel build to catch usage of deprecated APIs.
build:generic_clang --copt=-Wno-deprecated --host_copt=-Wno-deprecated
Introduce a Bazel build configuration This patch introduces configuration for a Bazel BUILD in a side directory in the monorepo. This is following the approval of https://github.com/llvm/llvm-www/blob/main/proposals/LP0002-BazelBuildConfiguration.md As detailed in the README, the Bazel BUILD is not supported by the community in general, and is maintained only by interested parties. It follows the requirements of the LLVM peripheral tier: https://llvm.org/docs/SupportPolicy.html#peripheral-tier. This is largely copied from https://github.com/google/llvm-bazel, with a few filepath tweaks and the addition of the README. Reviewed By: echristo, keith, dblaikie, kuhar Differential Revision: https://reviews.llvm.org/D90352
2021-05-19 06:42:25 +08:00
###############################################################################
# Options for "generic_gcc" builds: these options should generally apply to
# builds using a GCC-based compiler, and default to the `gcc` executable on
# the `PATH`. While these are provided for convenience and may serve as a
# reference, it would be preferable for users to configure an explicit C++
# toolchain instead of relying on `.bazelrc` files.
###############################################################################
# Set the default compiler to the `gcc` binary on the `PATH`.
build:generic_gcc --repo_env=CC=gcc
# C++14 standard version is required.
build:generic_gcc --cxxopt=-std=c++14 --host_cxxopt=-std=c++14
[Bazel] Don't fail the build on usage of deprecated APIs Build failures are not a particularly helpful way to enforce not using deprecated APIs and that isn't the point of the Bazel build. At the same time, this removes `-Wno-unused` this is a check that we do enforce in the Google internal build and so are ok maintaining in our maintenance of the upstream Bazel build (the comment about not wanting to do so was from a time when this was in a separate repository and I was the only one maintaining it). Differential Revision: https://reviews.llvm.org/D118671
2022-02-01 09:50:59 +08:00
# Build errors are not a helpful way to enforce deprecation in-repo and it is
# not the point of the Bazel build to catch usage of deprecated APIs.
build:generic_gcc --copt=-Wno-deprecated --host_copt=-Wno-deprecated
Introduce a Bazel build configuration This patch introduces configuration for a Bazel BUILD in a side directory in the monorepo. This is following the approval of https://github.com/llvm/llvm-www/blob/main/proposals/LP0002-BazelBuildConfiguration.md As detailed in the README, the Bazel BUILD is not supported by the community in general, and is maintained only by interested parties. It follows the requirements of the LLVM peripheral tier: https://llvm.org/docs/SupportPolicy.html#peripheral-tier. This is largely copied from https://github.com/google/llvm-bazel, with a few filepath tweaks and the addition of the README. Reviewed By: echristo, keith, dblaikie, kuhar Differential Revision: https://reviews.llvm.org/D90352
2021-05-19 06:42:25 +08:00
# Disable GCC warnings that are noisy and/or false positives on LLVM code.
# These need to be global as some code triggering these is in header files.
build:generic_gcc --copt=-Wno-unused-parameter --host_copt=-Wno-unused-parameter
build:generic_gcc --copt=-Wno-comment --host_copt=-Wno-comment
build:generic_gcc --cxxopt=-Wno-class-memaccess --host_cxxopt=-Wno-class-memaccess
build:generic_gcc --copt=-Wno-maybe-uninitialized --host_copt=-Wno-maybe-uninitialized
build:generic_gcc --copt=-Wno-misleading-indentation --host_copt=-Wno-misleading-indentation
# Use `-Werror` for GCC to make sure warnings don't slip past.
build:generic_gcc --copt=-Werror --host_copt=-Werror
###############################################################################
Add support for Bazel builds on Windows with `clang-cl`. Adds basic `--config=clang-cl` to set up the basic options needed, and then fix a number of issues that surface in Windows builds for me. With these fixes, `//llvm/...` builds cleanly. One unittest still fails, but its just due to running out of stack space due to creating a large number of short-lived stack variables. The test should probably be decomposed into a set of tests (`LegalizerInfoTest::RuleSets`), but that seemed like too invasive of a change here and with everything building cleanly this isn't disrupting me experimenting with Windows builds. Some parts of `//clang/...` builds, but that will require more work.
2021-10-16 15:46:19 +08:00
# Generic Windows flags common to both MSVC and Clang.
Introduce a Bazel build configuration This patch introduces configuration for a Bazel BUILD in a side directory in the monorepo. This is following the approval of https://github.com/llvm/llvm-www/blob/main/proposals/LP0002-BazelBuildConfiguration.md As detailed in the README, the Bazel BUILD is not supported by the community in general, and is maintained only by interested parties. It follows the requirements of the LLVM peripheral tier: https://llvm.org/docs/SupportPolicy.html#peripheral-tier. This is largely copied from https://github.com/google/llvm-bazel, with a few filepath tweaks and the addition of the README. Reviewed By: echristo, keith, dblaikie, kuhar Differential Revision: https://reviews.llvm.org/D90352
2021-05-19 06:42:25 +08:00
###############################################################################
[Bazel] Get `//clang` building on Windows with clang-cl. This required substantially more invasive changes. We need to handle some of the LLVM `config.h` changes differently from the old pattern. These aren't always safe on the commandline, and the Windows ones specifically break Clang. Instead, use conditional defines in the header itself. This more closely matches how CMake builds see the definitions. I think this is also just cleaner and we should maybe move more of the macros out of Bazel. The config defines for Windows that I've kept in Bazel are the ones that LLVM's CMake does at the commandline as well. I've also added numerous ones that CMake uses and we didn't replicate in Bazel. I also needed a different approach to get `libclang` working well. This, IMO, improves things on all platforms. Now we build the plugin and actually wrap it back up with `cc_import`. We have to use a collection of manually tagged `cc_binary` rules to get the naming to work out the right way, but this isn't too different from the prior approach. By directly having a `cc_binary` rule for each platform spelling of `libclang`, we can actually extract the interface library from it and correctly depend on it with `cc_import`. I think the result now is much closer to the intent and to the CMake build for libclang. Sadly, some tests also needed disabling. This is actually narrower than what CMake does. The issue isn't indicative of anything serious -- the test just assumes Unix-style paths. I also have cleaned up the Windows flags in `.bazelrc` to much more closely match what CMake does. Differential Revision: https://reviews.llvm.org/D112399
2021-11-02 10:52:38 +08:00
# C++14 standard version is required.
build:windows --cxxopt=/std:c++14 --host_cxxopt=/std:c++14
# Other generic dialect flags.
build:windows --copt=/Zc:strictStrings --host_copt=/Zc:strictStrings
build:windows --copt=/Oi --host_copt=/Oi
build:windows --cxxopt=/Zc:rvalueCast --host_cxxopt=/Zc:rvalueCast
# Use the more flexible bigobj format for C++ files that have lots of symbols.
build:windows --cxxopt=/bigobj --host_cxxopt=/bigobj
Add support for Bazel builds on Windows with `clang-cl`. Adds basic `--config=clang-cl` to set up the basic options needed, and then fix a number of issues that surface in Windows builds for me. With these fixes, `//llvm/...` builds cleanly. One unittest still fails, but its just due to running out of stack space due to creating a large number of short-lived stack variables. The test should probably be decomposed into a set of tests (`LegalizerInfoTest::RuleSets`), but that seemed like too invasive of a change here and with everything building cleanly this isn't disrupting me experimenting with Windows builds. Some parts of `//clang/...` builds, but that will require more work.
2021-10-16 15:46:19 +08:00
###############################################################################
# Windows specific flags for building with MSVC.
###############################################################################
build:msvc --config=windows
Introduce a Bazel build configuration This patch introduces configuration for a Bazel BUILD in a side directory in the monorepo. This is following the approval of https://github.com/llvm/llvm-www/blob/main/proposals/LP0002-BazelBuildConfiguration.md As detailed in the README, the Bazel BUILD is not supported by the community in general, and is maintained only by interested parties. It follows the requirements of the LLVM peripheral tier: https://llvm.org/docs/SupportPolicy.html#peripheral-tier. This is largely copied from https://github.com/google/llvm-bazel, with a few filepath tweaks and the addition of the README. Reviewed By: echristo, keith, dblaikie, kuhar Differential Revision: https://reviews.llvm.org/D90352
2021-05-19 06:42:25 +08:00
build:msvc --copt=/WX --host_copt=/WX # Treat warnings as errors...
# ...but disable the ones that are violated
build:msvc --copt=/wd4141 --host_copt=/wd4141 # inline used more than once
build:msvc --copt=/wd4244 --host_copt=/wd4244 # conversion type -> type
build:msvc --copt=/wd4267 --host_copt=/wd4267 # conversion size_t -> type
build:msvc --copt=/wd4273 --host_copt=/wd4273 # multiple definitions with different dllimport
build:msvc --copt=/wd4319 --host_copt=/wd4319 # zero-extending after complement
build:msvc --copt=/wd4624 --host_copt=/wd4624 # destructor was implicitly defined as deleted
build:msvc --copt=/wd4804 --host_copt=/wd4804 # comparisons between bool and int
build:msvc --copt=/wd4805 --host_copt=/wd4805 # comparisons between bool and int
build:msvc --linkopt=/WX --host_linkopt=/WX # Treat warnings as errors...
# ...but disable the ones that are violated.
build:msvc --linkopt=/IGNORE:4001 --host_linkopt=/IGNORE:4001 # no object files
Add support for Bazel builds on Windows with `clang-cl`. Adds basic `--config=clang-cl` to set up the basic options needed, and then fix a number of issues that surface in Windows builds for me. With these fixes, `//llvm/...` builds cleanly. One unittest still fails, but its just due to running out of stack space due to creating a large number of short-lived stack variables. The test should probably be decomposed into a set of tests (`LegalizerInfoTest::RuleSets`), but that seemed like too invasive of a change here and with everything building cleanly this isn't disrupting me experimenting with Windows builds. Some parts of `//clang/...` builds, but that will require more work.
2021-10-16 15:46:19 +08:00
###############################################################################
# Options for Windows `clang-cl` builds.
###############################################################################
# We just start with the baseline Windows config as `clang-cl` doesn't accept
# some of the generic Clang flags.
build:clang-cl --config=windows
# Switch from MSVC to the `clang-cl` compiler.
build:clang-cl --compiler=clang-cl
# Use Clang's internal warning flags instead of the ones that sometimes map
# through to MSVC's flags.
build:clang-cl --copt=/clang:-Wall --host_copt=/clang:-Wall
build:clang-cl --copt=/clang:-Werror --host_copt=/clang:-Werror
# This doesn't appear to be enforced by any upstream bot.
build:clang-cl --copt=/clang:-Wno-unused --host_copt=/clang:-Wno-unused
# There appears to be an unused constant in GoogleTest on Windows.
build:clang-cl --copt=/clang:-Wno-unused-const-variable --host_copt=/clang:-Wno-unused-const-variable
Introduce a Bazel build configuration This patch introduces configuration for a Bazel BUILD in a side directory in the monorepo. This is following the approval of https://github.com/llvm/llvm-www/blob/main/proposals/LP0002-BazelBuildConfiguration.md As detailed in the README, the Bazel BUILD is not supported by the community in general, and is maintained only by interested parties. It follows the requirements of the LLVM peripheral tier: https://llvm.org/docs/SupportPolicy.html#peripheral-tier. This is largely copied from https://github.com/google/llvm-bazel, with a few filepath tweaks and the addition of the README. Reviewed By: echristo, keith, dblaikie, kuhar Differential Revision: https://reviews.llvm.org/D90352
2021-05-19 06:42:25 +08:00
[Bazel] Get `//clang` building on Windows with clang-cl. This required substantially more invasive changes. We need to handle some of the LLVM `config.h` changes differently from the old pattern. These aren't always safe on the commandline, and the Windows ones specifically break Clang. Instead, use conditional defines in the header itself. This more closely matches how CMake builds see the definitions. I think this is also just cleaner and we should maybe move more of the macros out of Bazel. The config defines for Windows that I've kept in Bazel are the ones that LLVM's CMake does at the commandline as well. I've also added numerous ones that CMake uses and we didn't replicate in Bazel. I also needed a different approach to get `libclang` working well. This, IMO, improves things on all platforms. Now we build the plugin and actually wrap it back up with `cc_import`. We have to use a collection of manually tagged `cc_binary` rules to get the naming to work out the right way, but this isn't too different from the prior approach. By directly having a `cc_binary` rule for each platform spelling of `libclang`, we can actually extract the interface library from it and correctly depend on it with `cc_import`. I think the result now is much closer to the intent and to the CMake build for libclang. Sadly, some tests also needed disabling. This is actually narrower than what CMake does. The issue isn't indicative of anything serious -- the test just assumes Unix-style paths. I also have cleaned up the Windows flags in `.bazelrc` to much more closely match what CMake does. Differential Revision: https://reviews.llvm.org/D112399
2021-11-02 10:52:38 +08:00
# Disable some warnings hit even with `clang-cl` in Clang's own code.
build:clang-cl --copt=/clang:-Wno-inconsistent-dllimport --host_copt=/clang:-Wno-inconsistent-dllimport
build:clang-cl --cxxopt=/clang:-Wno-c++11-narrowing --host_cxxopt=/clang:-Wno-c++11-narrowing
Introduce a Bazel build configuration This patch introduces configuration for a Bazel BUILD in a side directory in the monorepo. This is following the approval of https://github.com/llvm/llvm-www/blob/main/proposals/LP0002-BazelBuildConfiguration.md As detailed in the README, the Bazel BUILD is not supported by the community in general, and is maintained only by interested parties. It follows the requirements of the LLVM peripheral tier: https://llvm.org/docs/SupportPolicy.html#peripheral-tier. This is largely copied from https://github.com/google/llvm-bazel, with a few filepath tweaks and the addition of the README. Reviewed By: echristo, keith, dblaikie, kuhar Differential Revision: https://reviews.llvm.org/D90352
2021-05-19 06:42:25 +08:00
###############################################################################
###############################################################################
# Configuration for building remotely using Remote Build Execution (RBE)
# Based on https://github.com/bazelbuild/bazel-toolchains/blob/master/bazelrc/bazel-1.0.0.bazelrc
###############################################################################
build:rbe --remote_instance_name=projects/llvm-bazel/instances/default_instance
# Depending on how many machines are in the remote execution instance, setting
# this higher can make builds faster by allowing more jobs to run in parallel.
# Setting it too high can result in jobs that timeout, however, while waiting
# for a remote machine to execute them.
build:rbe --jobs=150
# Set several flags related to specifying the platform, toolchain and java
# properties.
# These flags should only be used as is for the rbe-ubuntu16-04 container
# and need to be adapted to work with other toolchain containers.
build:rbe --host_javabase=@rbe_default//java:jdk
build:rbe --javabase=@rbe_default//java:jdk
build:rbe --host_java_toolchain=@bazel_tools//tools/jdk:toolchain_hostjdk8
build:rbe --java_toolchain=@bazel_tools//tools/jdk:toolchain_hostjdk8
build:rbe --crosstool_top=@rbe_default//cc:toolchain
build:rbe --action_env=BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN=1
# Platform flags:
# The toolchain container used for execution is defined in the target indicated
# by "extra_execution_platforms", "host_platform" and "platforms".
[NFC] Inclusive language: Remove instances of master in URLs [NFC] This patch fixes URLs containing "master". Old URLs were either broken or redirecting to the new URL. Reviewed By: #libc, ldionne, mehdi_amini Differential Revision: https://reviews.llvm.org/D113186
2021-11-04 03:41:24 +08:00
# More about platforms: https://docs.bazel.build/versions/main/platforms.html
Introduce a Bazel build configuration This patch introduces configuration for a Bazel BUILD in a side directory in the monorepo. This is following the approval of https://github.com/llvm/llvm-www/blob/main/proposals/LP0002-BazelBuildConfiguration.md As detailed in the README, the Bazel BUILD is not supported by the community in general, and is maintained only by interested parties. It follows the requirements of the LLVM peripheral tier: https://llvm.org/docs/SupportPolicy.html#peripheral-tier. This is largely copied from https://github.com/google/llvm-bazel, with a few filepath tweaks and the addition of the README. Reviewed By: echristo, keith, dblaikie, kuhar Differential Revision: https://reviews.llvm.org/D90352
2021-05-19 06:42:25 +08:00
build:rbe --extra_toolchains=@rbe_default//config:cc-toolchain
build:rbe --extra_execution_platforms=@rbe_default//config:platform
build:rbe --host_platform=@rbe_default//config:platform
build:rbe --platforms=@rbe_default//config:platform
build:rbe --define=EXECUTOR=remote
# Enable remote execution so actions are performed on the remote systems.
build:rbe --remote_executor=grpcs://remotebuildexecution.googleapis.com
# Enforce stricter environment rules, which eliminates some non-hermetic
# behavior and therefore improves both the remote cache hit rate and the
# correctness and repeatability of the build.
build:rbe --incompatible_strict_action_env=true
# Set a higher timeout value, just in case.
build:rbe --remote_timeout=3600
# Local disk cache is incompatible with remote execution (for obvious reasons).
build:rbe --disk_cache=""
# Enable authentication. This will pick up application default credentials by
# default. You can use --google_credentials=some_file.json to use a service
# account credential instead.
build:rbe --google_default_credentials=true
# The user.bazelrc file is not checked in but available for local mods.
# Always keep this at the end of the file so that user flags override.
try-import %workspace%/user.bazelrc