8567e3a5c7
This lets us drop various patches and go all the way to a very clean setup. In case folks are curious what was going on... we were depending on the toolchain finding stdlib headers as sibling files of `clang++`, and for linking we were providing a `-resource-dir` containing the runtime libs. However, some users of the cc toolchain (such as rust build scripts) do the equivalent of `$CC $CCFLAGS $LDFLAGS` so the `-resource-dir` was being passed when compiling, which suppressed the default stdlib header location logic. The upstream fix was to swap to using `-isystem` to pass the stdlib headers, while carefully controlling the ordering to simulate them coming from the resource-dir.
62 lines
2.7 KiB
Text
62 lines
2.7 KiB
Text
common --repo_env=BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN=1
|
|
common --repo_env=BAZEL_NO_APPLE_CPP_TOOLCHAIN=1
|
|
# Dummy xcode config so we don't need to build xcode_locator in repo rule.
|
|
common --xcode_version_config=//:disable_xcode
|
|
|
|
common --disk_cache=~/.cache/bazel-disk-cache
|
|
common --repo_contents_cache=~/.cache/bazel-repo-contents-cache
|
|
common --repository_cache=~/.cache/bazel-repo-cache
|
|
common --remote_cache_compression
|
|
startup --experimental_remote_repo_contents_cache
|
|
|
|
common --experimental_platform_in_output_dir
|
|
|
|
# Runfiles strategy rationale: codex-rs/utils/cargo-bin/README.md
|
|
common --noenable_runfiles
|
|
|
|
common --enable_platform_specific_config
|
|
common:linux --host_platform=//:local_linux
|
|
common:windows --host_platform=//:local_windows
|
|
common --@rules_cc//cc/toolchains/args/archiver_flags:use_libtool_on_macos=False
|
|
common --@llvm//config:experimental_stub_libgcc_s
|
|
|
|
# We need to use the sh toolchain on windows so we don't send host bash paths to the linux executor.
|
|
common:windows --@rules_rust//rust/settings:experimental_use_sh_toolchain_for_bootstrap_process_wrapper
|
|
|
|
# TODO(zbarsky): rules_rust doesn't implement this flag properly with remote exec...
|
|
# common --@rules_rust//rust/settings:pipelined_compilation
|
|
|
|
common --incompatible_strict_action_env
|
|
# Not ideal, but We need to allow dotslash to be found
|
|
common:linux --test_env=PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
|
|
common:macos --test_env=PATH=/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
|
|
|
|
# Pass through some env vars Windows needs to use powershell?
|
|
common:windows --test_env=PATH
|
|
common:windows --test_env=SYSTEMROOT
|
|
common:windows --test_env=COMSPEC
|
|
common:windows --test_env=WINDIR
|
|
|
|
common --test_output=errors
|
|
common --bes_results_url=https://app.buildbuddy.io/invocation/
|
|
common --bes_backend=grpcs://remote.buildbuddy.io
|
|
common --remote_cache=grpcs://remote.buildbuddy.io
|
|
common --remote_download_toplevel
|
|
common --nobuild_runfile_links
|
|
common --remote_timeout=3600
|
|
common --noexperimental_throttle_remote_action_building
|
|
common --experimental_remote_execution_keepalive
|
|
common --grpc_keepalive_time=30s
|
|
|
|
# This limits both in-flight executions and concurrent downloads. Even with high number
|
|
# of jobs execution will still be limited by CPU cores, so this just pays a bit of
|
|
# memory in exchange for higher download concurrency.
|
|
common --jobs=30
|
|
|
|
common:remote --extra_execution_platforms=//:rbe
|
|
common:remote --remote_executor=grpcs://remote.buildbuddy.io
|
|
common:remote --jobs=800
|
|
# TODO(team): Evaluate if this actually helps, zbarsky is not sure, everything seems bottlenecked on `core` either way.
|
|
# Enable pipelined compilation since we are not bound by local CPU count.
|
|
#common:remote --@rules_rust//rust/settings:pipelined_compilation
|
|
|