.bazelrc

common --noenable_bzlmod
common:bzlmod --enable_bzlmod --noenable_workspace

common --incompatible_enable_cc_toolchain_resolution     # Only for bazel 6.5: C++ rules use platforms to select toolchains when you set this
build --toolchain_resolution_debug=.*
build --cxxopt=-std=c++17
build --repo_env=HERMETIC_PYTHON_VERSION=3.11

common:clang_local --noincompatible_enable_cc_toolchain_resolution
build:clang_local --@rules_ml_toolchain//common:enable_hermetic_cc=False
build:clang_local --repo_env USE_HERMETIC_CC_TOOLCHAIN=0

# Use linux_clang_local flag for local clang testing
common:linux_clang_local --config=clang_local
common:linux_clang_local --host_crosstool_top="@local_config_cuda//crosstool:toolchain"
common:linux_clang_local --crosstool_top="@local_config_cuda//crosstool:toolchain"

# Disable clang extention that rejects type definitions within offsetof.
# This was added in clang-16 by https://reviews.llvm.org/D133574.
# Can be removed once upb is updated, since a type definition is used within
# offset of in the current version of ubp.
# See https://github.com/protocolbuffers/upb/blob/9effcbcb27f0a665f9f345030188c0b291e32482/upb/upb.c#L183.
build:clang --copt=-Wno-gnu-offsetof-extensions

# Disable clang extention that rejects unknown arguments.
build:clang --copt=-Qunused-arguments

# Error on struct/class mismatches, since this causes link failures on Windows.
build:clang --copt=-Werror=mismatched-tags

# Hermetic ASan configuration example. Hermetic ASan works only for Linux x86_64
common:asan --platforms=@rules_ml_toolchain//common:linux_x86_64_with_sanitizers
common:asan --features=asan
common:asan --strip=never

# Hermetic TSan configuration example. Hermetic TSan works only for Linux x86_64
common:tsan --platforms=@rules_ml_toolchain//common:linux_x86_64_with_sanitizers
common:tsan --features=tsan
common:tsan --strip=never

# We need successfully finished tests to check that TSan works. Only for this purpose we add TSan options 'halt_on_error=1:exitcode=66'
# TODO: How to make it work with different versions of LLVM?
common:tsan_test --test_env="TSAN_OPTIONS="halt_on_error=1:exitcode=66:external_symbolizer_path=../../external/llvm18_linux_x86_64/bin/llvm-symbolizer"

# Non-hermetic ASan configuration
common:asan_clang_local --copt=-fsanitize=address
common:asan_clang_local --linkopt=-fsanitize=address
common:asan_clang_local --strip=never

# Non-hermetic TSan configuration
common:tsan_clang_local --copt=-fsanitize=thread
common:tsan_clang_local --linkopt=-fsanitize=thread
common:tsan_clang_local --strip=never

# Configs for CUDA
common:cuda_v12 --repo_env=HERMETIC_CUDA_VERSION="12.9.1"
common:cuda_v12 --repo_env=HERMETIC_CUDNN_VERSION="9.8.0"
common:cuda_v12 --repo_env=HERMETIC_NVSHMEM_VERSION="3.3.9"
common:cuda_v12 --repo_env=HERMETIC_NCCL_VERSION="2.27.7"
# "sm" means we emit only cubin, which is forward compatible within a GPU generation.
# "compute" means we emit both cubin and PTX, which is larger but also forward compatible to future GPU generations.
common:cuda_v12 --repo_env HERMETIC_CUDA_COMPUTE_CAPABILITIES="sm_50,sm_60,sm_70,sm_80,sm_90,sm_100,compute_120"

common:cuda_v13 --repo_env=HERMETIC_CUDA_VERSION="13.0.0"
common:cuda_v13 --repo_env=HERMETIC_CUDNN_VERSION="9.12.0"
common:cuda_v13 --repo_env=HERMETIC_NVSHMEM_VERSION="3.3.20"
common:cuda_v13 --repo_env=HERMETIC_NCCL_VERSION="2.27.7"
common:cuda_v13 --repo_env HERMETIC_CUDA_COMPUTE_CAPABILITIES="sm_75,sm_80,sm_90,sm_100,compute_120"

common:cuda_common --repo_env TF_NEED_CUDA=1
common:cuda_common --repo_env TF_NCCL_USE_STUB=1
common:cuda_common --@rules_ml_toolchain//common:enable_cuda
common:cuda_common --@local_config_cuda//cuda:include_cuda_libs=true

# Force the linker to set RPATH, not RUNPATH. When resolving dynamic libraries,
# ld.so prefers in order: RPATH, LD_LIBRARY_PATH, RUNPATH. JAX sets RPATH to
# point to the $ORIGIN-relative location of the pip-installed NVIDIA CUDA
# packages.
# This has pros and cons:
# * pro: we'll ignore other CUDA installations, which has frequently confused
#   users in the past. By setting RPATH, we'll always use the NVIDIA pip
#   packages if they are installed.
# * con: the user cannot override the CUDA installation location
#   via LD_LIBRARY_PATH, if the nvidia-... pip packages are installed. This is
#   acceptable, because the workaround is "remove the nvidia-..." pip packages.
# The list of CUDA pip packages that JAX depends on are present in setup.py.
common:cuda_common --linkopt=-Wl,--disable-new-dtags

common:cuda12 --config=cuda_common
common:cuda12 --config=cuda_v12

common:cuda13 --config=cuda_common
common:cuda13 --config=cuda_v13

# Alias for backward compatibility.
common:cuda --config=cuda12

# This config is used for building targets with CUDA libraries from stubs.
build:cuda_libraries_from_stubs --@local_config_cuda//cuda:include_cuda_libs=false

common:hermetic_cuda_umd --@cuda_driver//:include_cuda_umd_libs=true

# common CUDA and other C++ targets with Clang
common:build_cuda_with_clang --@local_config_cuda//:cuda_compiler=clang

# common CUDA with NVCC and other C++ targets with Clang
common:build_cuda_with_nvcc --action_env=TF_NVCC_CLANG="1"
common:build_cuda_with_nvcc --@local_config_cuda//:cuda_compiler=nvcc

# Force the linker to set RPATH, not RUNPATH. When resolving dynamic libraries,
# ld.so prefers in order: RPATH, LD_LIBRARY_PATH, RUNPATH. JAX sets RPATH to
# point to the $ORIGIN-relative location of the pip-installed NVIDIA CUDA
# packages.
# This has pros and cons:
# * pro: we'll ignore other CUDA installations, which has frequently confused
#   users in the past. By setting RPATH, we'll always use the NVIDIA pip
#   packages if they are installed.
# * con: the user cannot override the CUDA installation location
#   via LD_LIBRARY_PATH, if the nvidia-... pip packages are installed. This is
#   acceptable, because the workaround is "remove the nvidia-..." pip packages.
# The list of CUDA pip packages that JAX depends on are present in setup.py.
build:cuda --linkopt=-Wl,--disable-new-dtags

build:cuda_clang_local --config=cuda
build:cuda_clang_local --config=clang_local
build:cuda_clang_local --crosstool_top=@local_config_cuda//crosstool:toolchain

# Build CUDA and other C++ targets with Clang
build:build_cuda_with_clang --@local_config_cuda//:cuda_compiler=clang

# Build CUDA with NVCC and other C++ targets with Clang
build:build_cuda_with_nvcc --action_env=TF_NVCC_CLANG="1"
build:build_cuda_with_nvcc --@local_config_cuda//:cuda_compiler=nvcc

# #############################################################################
# Feature-specific configurations. These are used by the CI configs below
# depending on the type of build. E.g. `ci_linux_x86_64` inherits the Linux x86
# configs such as `avx_linux` and `mkl_open_source_only`, `ci_linux_x86_64_cuda`
# inherits `cuda` and `build_cuda_with_nvcc`, etc.
# #############################################################################
build:nonccl --define=no_nccl_support=true

build:posix --copt=-fvisibility=hidden
build:posix --copt=-Wno-sign-compare
build:posix --cxxopt=-std=c++17
build:posix --host_cxxopt=-std=c++17

build:avx_posix --copt=-mavx
build:avx_posix --host_copt=-mavx

build:native_arch_posix --copt=-march=native
build:native_arch_posix --host_copt=-march=native

build:avx_linux --copt=-mavx
build:avx_linux --host_copt=-mavx

build:avx_windows --copt=/arch:AVX

build:mkl_open_source_only --define=tensorflow_mkldnn_contraction_kernel=1

# Config setting to build oneDNN with Compute Library for the Arm Architecture (ACL).
build:mkl_aarch64_threadpool --define=build_with_mkl_aarch64=true
build:mkl_aarch64_threadpool --@compute_library//:openmp=false
build:mkl_aarch64_threadpool -c opt

# #############################################################################
# CI Build config options below.
# JAX uses these configs in CI builds for building artifacts and when running
# Bazel tests.
# #############################################################################
# Linux x86 CI configs
build:ci_linux_x86_64 --config=avx_linux --config=avx_posix
build:ci_linux_x86_64 --config=mkl_open_source_only
build:ci_linux_x86_64 --config=clang --verbose_failures=true
build:ci_linux_x86_64 --color=yes

# TODO(b/356695103): We do not have a CPU only toolchain so we use the CUDA
# toolchain for both CPU and GPU builds.
build:ci_linux_x86_64_clang --config=ci_linux_x86_64

# The toolchain in `--config=cuda` needs to be read before the toolchain in
# `--config=ci_linux_x86_64`. Otherwise, we run into issues with manylinux
# compliance.
build:ci_linux_x86_64_cuda --config=cuda --config=build_cuda_with_nvcc
build:ci_linux_x86_64_cuda --config=ci_linux_x86_64

# #############################################################################
# This config option is used for SYCL as GPU backend.
# #############################################################################
# Non-hermetic SYCL Configuration
build:sycl --@rules_ml_toolchain//common:enable_sycl=True
build:sycl --define=tensorflow_mkldnn_contraction_kernel=0
build:sycl --repo_env=TF_NEED_SYCL=1
build:sycl --cxxopt=-std=c++17
build:sycl --repo_env=SYCL_BUILD_HERMETIC=0

# Hermetic SYCL Configuration
build:sycl_hermetic --config=sycl
build:sycl_hermetic --repo_env=SYCL_BUILD_HERMETIC=1
build:sycl_hermetic --repo_env=ONEAPI_VERSION=2025.1
build:sycl_hermetic --repo_env=OS=ubuntu_24.10

# Enable Clang for host and icpx for SYCL
build:icpx_clang --repo_env TF_ICPX_CLANG=1
build:icpx_clang --copt=-fclang-abi-compat=17
build:icpx_clang --copt=-fsycl-unnamed-lambda