search

bazelbuild / bazel

a fast, scalable, multi-language and extensible build system
https://bazel.build
Apache License 2.0
23.26k stars 4.08k forks source link

Conflicting build configs in .bazelrc files are being overridden according to documented precedence #11976

Closed aohren closed 1 year ago

aohren commented 4 years ago

Description of the problem / feature request:

Config definition in ~/.bazelrc doesn't override conflicting definition in workspace .bazelrc.

Given the --announce_rc findings below,

INFO: Reading rc options for 'build' from /usr/local/google/home/aohren/test-workspace/.bazelrc:
  'build' options: --enable_platform_specific_config
INFO: Reading rc options for 'build' from /usr/local/google/home/aohren/.bazelrc:
  'build' options: --enable_platform_specific_config
INFO: Found applicable config definition build:linux in file /usr/local/google/home/aohren/test-workspace/.bazelrc: --sandbox_tmpfs_path=/tmpfs/tmp
INFO: Found applicable config definition build:linux in file /usr/local/google/home/aohren/.bazelrc: --sandbox_tmpfs_path=/tmp

I'd expect the build to use sandbox_tmpfs_path=/tmp. The docs to imply the ~/.bazelrc should override the conflicting definition in the workspace's .bazelrc.

However, the builds always use sandbox_tmpfs_path=/tmpfs/tmp, even if the .bazelrc files are swapped.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

$:~/test-workspace$ cat $HOME/.bazelrc
build --enable_platform_specific_config
build:linux --sandbox_tmpfs_path=/tmp
$:~/test-workspace$ cat ./.bazelrc
build --enable_platform_specific_config
build:linux --sandbox_tmpfs_path=/tmpfs/tmp
$:~/test-workspace$ bazel build --announce_rc ...
INFO: Options provided by the client:
  Inherited 'common' options: --isatty=1 --terminal_columns=249
INFO: Reading rc options for 'build' from /usr/local/google/home/aohren/test-workspace/.bazelrc:
  'build' options: --enable_platform_specific_config
INFO: Reading rc options for 'build' from /usr/local/google/home/aohren/.bazelrc:
  'build' options: --enable_platform_specific_config
INFO: Found applicable config definition build:linux in file /usr/local/google/home/aohren/test-workspace/.bazelrc: --sandbox_tmpfs_path=/tmpfs/tmp
INFO: Found applicable config definition build:linux in file /usr/local/google/home/aohren/.bazelrc: --sandbox_tmpfs_path=/tmp
INFO: Analyzed target //:hello (14 packages loaded, 47 targets configured).
INFO: Found 1 target...
ERROR: /usr/local/google/home/aohren/test-workspace/BUILD.bazel:1:10: C++ compilation of rule '//:hello' failed (Exit 1) gcc failed: error executing command /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -MD -MF bazel-out/k8-fastbuild/bin/_objs/hello/hello.pic.d ... (remaining 19 argument(s) skipped)

Use --sandbox_debug to see verbose messages from the sandbox
src/main/tools/linux-sandbox-pid1.cc:170: "mount(tmpfs, /tmpfs/tmp, tmpfs, MS_NOSUID | MS_NODEV | MS_NOATIME, nullptr)": No such file or directory
Target //:hello failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 0.452s, Critical Path: 0.05s
INFO: 0 processes.
FAILED: Build did NOT complete successfully

What operating system are you running Bazel on?

Linux

What's the output of bazel info release?

release 3.4.1

If bazel info release returns "development version" or "(@non-git)", tell us how you built Bazel.

N/A

What's the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?

N/A (installed with apt-get)

Have you found anything relevant by searching the web?

According to .bazelrc docs, the $HOME/.bazelrc should be found after the workspace .bazelrc file and "options in later files can override a value from an earlier file if a conflict arises". This doesn't appear to be the case with the build:linux --sandbox_tmpfs_path=... snippet provided above.

Any other information, logs, or outputs that you want to share?

Running with --announce_rc indicates Bazel is finding both .bazelrcs in the right order and even interperting the configs in the right ordrer:

INFO: Found applicable config definition build:linux in file /usr/local/google/home/aohren/test-workspace/.bazelrc: --sandbox_tmpfs_path=/tmpfs/tmp
INFO: Found applicable config definition build:linux in file /usr/local/google/home/aohren/.bazelrc: --sandbox_tmpfs_path=/tmp

But the config in HOME (sandbox_tmpfs_path=/tmp) is not overriding the workspace config (sandbox_tmpfs_path=/tmpfs/tmp):

src/main/tools/linux-sandbox-pid1.cc:170: "mount(tmpfs, /tmpfs/tmp, tmpfs, MS_NOSUID | MS_NODEV | MS_NOATIME, nullptr)": No such file or directory

In fact, changing the order around doesn't seem to affect things either. It's always picking sandbox_tmpfs_path=/tmpfs/tmp:

$:~/test-workspace$ bazel build --announce_rc ...
INFO: Options provided by the client:
  Inherited 'common' options: --isatty=1 --terminal_columns=249
INFO: Reading rc options for 'build' from /usr/local/google/home/aohren/test-workspace/.bazelrc:
  'build' options: --enable_platform_specific_config
INFO: Reading rc options for 'build' from /usr/local/google/home/aohren/.bazelrc:
  'build' options: --enable_platform_specific_config
INFO: Found applicable config definition build:linux in file /usr/local/google/home/aohren/test-workspace/.bazelrc: --sandbox_tmpfs_path=/tmp
INFO: Found applicable config definition build:linux in file /usr/local/google/home/aohren/.bazelrc: --sandbox_tmpfs_path=/tmpfs/tmp
INFO: Analyzed target //:hello (14 packages loaded, 47 targets configured).
INFO: Found 1 target...
ERROR: /usr/local/google/home/aohren/test-workspace/BUILD.bazel:1:10: C++ compilation of rule '//:hello' failed (Exit 1) gcc failed: error executing command /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -MD -MF bazel-out/k8-fastbuild/bin/_objs/hello/hello.pic.d ... (remaining 19 argument(s) skipped)

Use --sandbox_debug to see verbose messages from the sandbox
src/main/tools/linux-sandbox-pid1.cc:170: "mount(tmpfs, /tmpfs/tmp, tmpfs, MS_NOSUID | MS_NODEV | MS_NOATIME, nullptr)": No such file or directory
Target //:hello failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 0.443s, Critical Path: 0.05s
INFO: 0 processes.
FAILED: Build did NOT complete successfully
aranguyen commented 2 years ago

@aohren I'm not familiar with the flags --sandbox_tmpfs_path and --sandbox_debug. How is the output src/main/tools/linux-sandbox-pid1.cc:170: "mount(tmpfs, /tmpfs/tmp, tmpfs, MS_NOSUID | MS_NODEV | MS_NOATIME, nullptr)": No such file or directory an indication that the build is always using sandbox_tmpfs_path=/tmpfs/tmp?

I instead did a repro using standard built-in flags --cpu, -c, and a Starlark string flag. I observed that conflicting flags in HOME rc-file override flags in workspace rc-file as documented. My repro:

HOME rc-file

$cat ~/.bazelrc
build --enable_platform_specific_config
build --//:flag=home-rc-flag

build:macos --cpu=x86 
build:macos -c dbg

WORKSPACE rc-file

$cat $WORKSPACE/.bazelrc
build --enable_platform_specific_config
build --//:flag=home-rc-flag

build:macos --cpu=k8
build:macos -c opt

Running bazel build ... with the build completed successfully. For the Starlark flag, the DEBUG statement shows 

DEBUG: /Users/aranguyen/examples/flags-parsing-tutorial/build_defs.bzl:6:10: evaluated value for flag: home-rc-flag

For flags --cpu and -c, I observed x86-dbg in the output path by running ls -l. 

lrwxr-xr-x  1 aranguyen  primarygroup       118 Dec 28 23:39 bazel-bin -> /private/var/tmp/_bazel_aranguyen/f6862eb0fe4a0fdb956656ac82e79518/execroot/flagsparsingexamples/bazel-out/x86-dbg/bin

I also notice that there was error in your repro's output. Could you please make sure the build is completed successfully and retry?

github-actions[bot] commented 1 year ago

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

github-actions[bot] commented 1 year ago

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!