-
Notifications
You must be signed in to change notification settings - Fork 15.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use_default_shell_env leads to spurious rebuilds #6886
Comments
We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment. This issue is labeled |
We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please reopen it. This issue was closed and archived because there has been no new activity in the 14 days since the |
Describe the problem you are trying to solve.
#2933 introduced a workaround for bazelbuild/bazel#2515. This workaround consists in weakening the hermeticity of the protobuf component of any user's build, by allowing protobuf to depend on
LD_LIBRARY_PATH
and other environment variables set externally to the build. The problem is that this leads to more frequent rebuilds of all of protobuf. Anytime thePATH
or other environment variable changes (which on some systems can happen very frequently), the build cache is invalidated. Since protobuf is a very common dependency very deep in the dependency tree, rebuilding protobuf will affect many users many times. On my team, protobuf rebuilds have become the one thing Bazel is infamous for.Describe the solution you'd like
Revert #2933. I would argue that setting the right environment variables should be a matter for the toolchain configuration, and that toolchains should otherwise be hermetic. This would lead to far fewer cache invalidations anytime the state of the host environment changes.
Describe alternatives you've considered
An alternative would be to pass through only some variables from the environment, say
LD_LIBRARY_PATH
, but notPATH
. However, this only partially solves the problem above.The text was updated successfully, but these errors were encountered: