-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Expand file tree
/
Copy path.bazelrc
More file actions
44 lines (40 loc) · 2.07 KB
/
Copy path.bazelrc
File metadata and controls
44 lines (40 loc) · 2.07 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
# Bazel 7.7.0 remains pinned in .bazelversion. Bzlmod is TensorBoard's only
# supported dependency-resolution entry point. WORKSPACE.bzlmod is an internal
# compatibility bridge for dependencies that do not yet expose module APIs.
# Bazel must still evaluate that bridge, so --noenable_workspace is not yet
# supported even though --noenable_bzlmod is intentionally unsupported.
common --enable_bzlmod
# Let the OS-specific sections below (`common:linux`, `common:macos`, etc.)
# take effect so one `.bazelrc` can carry the required per-platform C++ flags.
common --enable_platform_specific_config
common --experimental_repo_remote_exec # from TensorFlow
# Bazel-generated Python package init files can shadow TensorBoard's real
# compat package init at test runtime; keep this test-only so pip packaging
# still copies the intended package tree.
test --incompatible_default_to_explicit_init_py
# Use C++ backing implementations for Python proto parsing and deserialization,
# which is much faster (~10x).
build --define=use_fast_cpp_protos=true
# Use Bazel's hermetic JDK 21 for Java targets and build tools. The default
# target runtime is the host JDK, which can be newer than Bazel 7's Java
# compiler and make otherwise unrelated Java compilation fail.
build --java_runtime_version=remotejdk_21
build --tool_java_runtime_version=remotejdk_21
# Protobuf 6.31.1 requires C++17 in this build. Keep the host and target
# language level aligned across supported platforms.
common:linux --cxxopt=-std=c++17
common:linux --host_cxxopt=-std=c++17
common:macos --cxxopt=-std=c++17
common:macos --host_cxxopt=-std=c++17
common:windows --cxxopt=/std:c++17
common:windows --host_cxxopt=/std:c++17
# Local shells and virtualenvs can leak Python import state into Bazel tests,
# which then import from the wrong environment instead of the test runfiles.
test --test_env=PYTHONPATH=
test --test_env=PYTHONHOME=
test --test_env=PYTHONSTARTUP=
test --test_env=PYTHONSAFEPATH=
test --test_env=PYTHONNOUSERSITE=1
test --test_env=PYTHONUSERBASE=
test --test_env=BUILD_WORKSPACE_DIRECTORY=
test --test_env=BUILD_WORKING_DIRECTORY=