When using the newly added --host_action_env flag, the analysis phase fails with lots of file X is generated by these conflicting actions type errors.
Example error log:
ERROR: file 'external/local_config_cc/watchos_i386.runfiles/MANIFEST' is generated by these conflicting actions:
Label: @local_config_cc//:watchos_i386
RuleClass: cc_toolchain_config rule
Configuration: cafef9f8b89de695d623b93423eb2b4d32ac34d4f9b36496f8139f880d1f4901, 9177372694e283f2d9a7ff337e520a3c2f33deeddac5d93aa911522a084518e2
Mnemonic: SymlinkTree
Action key: b5ecb575df0ad57da108b32678bdc98502e8f791db66d410fbe929282f7722a7, e1b483e3ef545df17ef13fe03742f0be50941c7e2835dc3560ae5b4c8878fe15
Progress message: Creating runfiles tree bazel-out/darwin-opt-exec-2B5CBBC6/bin/external/local_config_cc/watchos_i386.runfiles
PrimaryInput: File:[[<execution_root>]bazel-out/darwin-opt-exec-2B5CBBC6/bin]external/local_config_cc/watchos_i386.runfiles_manifest
PrimaryOutput: File:[[<execution_root>]bazel-out/darwin-opt-exec-2B5CBBC6/bin]external/local_config_cc/watchos_i386.runfiles/MANIFEST
Owner information: ConfiguredTargetKey{label=@local_config_cc//:watchos_i386, config=BuildConfigurationValue.Key[cafef9f8b89de695d623b93423eb2b4d32ac34d4f9b36496f8139f880d1f4901]}, ConfiguredTargetKey{label=@local_config_cc//:watchos_i386, config=BuildConfigurationValue.Key[9177372694e283f2d9a7ff337e520a3c2f33deeddac5d93aa911522a084518e2]}
MandatoryInputs: are equal
Outputs: are equal
WARNING: errors encountered while analyzing target '@local_config_cc//:watchos_i386': it will not be built
Most failures are for local_config_cc, but there are also 2 for the protobuf library. They are not directly related to the targets I'm trying to build.
ERROR: file 'external/local_config_cc/watchos_armv7k.runfiles/MANIFEST' is generated by these conflicting actions:
ERROR: file 'external/com_google_protobuf/compiler_plugin_proto-descriptor-set.proto.bin' is generated by these conflicting actions:
ERROR: file 'external/local_config_cc/ios_arm64e.runfiles/MANIFEST' is generated by these conflicting actions:
ERROR: file 'external/local_config_cc/watchos_i386.runfiles/MANIFEST' is generated by these conflicting actions:
ERROR: file 'external/local_config_cc/ios_i386.runfiles/MANIFEST' is generated by these conflicting actions:
ERROR: file 'external/local_config_cc/ios_arm64.runfiles/MANIFEST' is generated by these conflicting actions:
ERROR: file 'external/local_config_cc/tvos_arm64.runfiles/MANIFEST' is generated by these conflicting actions:
ERROR: file 'external/local_config_cc/tvos_x86_64.runfiles/MANIFEST' is generated by these conflicting actions:
ERROR: file 'external/local_config_cc/stub_armeabi-v7a.runfiles/MANIFEST' is generated by these conflicting actions:
ERROR: file 'external/local_config_cc/darwin_arm64.runfiles/MANIFEST' is generated by these conflicting actions:
ERROR: file 'external/local_config_cc/ios_x86_64.runfiles/MANIFEST' is generated by these conflicting actions:
ERROR: file 'external/local_config_cc/watchos_arm64_32.runfiles/MANIFEST' is generated by these conflicting actions:
ERROR: file 'external/local_config_cc/darwin_x86_64.runfiles/MANIFEST' is generated by these conflicting actions:
ERROR: file 'external/local_config_cc/darwin_arm64e.runfiles/MANIFEST' is generated by these conflicting actions:
ERROR: file 'external/local_config_cc/ios_armv7.runfiles/MANIFEST' is generated by these conflicting actions:
ERROR: file 'external/local_config_cc/watchos_x86_64.runfiles/MANIFEST' is generated by these conflicting actions:
ERROR: file 'external/com_google_protobuf/descriptor_proto-descriptor-set.proto.bin' is generated by these conflicting actions:
When I run bazel config on these 2 configurations (cafef9f and 9177372), the only difference between the 2 configs is for com.google.devtools.build.lib.analysis.config.CoreOptions.action_env where one config includes the env var and the other doesn't.
I also tried to run bazel cquery --host_action_env=FOO 'somepath(@com_google_protobuf//:descriptor_proto, //path/to/pkg)' but this fails for the same reason.
I'm not sure if I've missed something when upgrading Bazel to 3.7.0, if I'm misusing / misconfiguring something, or if there's an actual issue. Any help would be greatly appreciated!
Build successfully without errors.
I've created a workspace that reproduces this error: https://github.com/martinxsliu/testgo.
Run make to see build errors.
macOS Catalina 10.15.7
bazel info release?release 3.7.0
Issue: https://github.com/bazelbuild/bazel/issues/4008
PR to add the --host_action_env flag: https://github.com/bazelbuild/bazel/pull/12122
Can you test with this patch https://github.com/bazelbuild/bazel/pull/12265 to see if it's resolved?
@keith Unfortunately it did not resolve the issue on the test repo I set up. However, when I tried in my main workspace, the compiled from source Bazel crashed on start up so it's possible that the binary wasn't properly built or configured properly for my machine (I tried compiling v3.7.0 from source and it also crashed).
Are you able to repro / test your patch on the test repo https://github.com/martinxsliu/testgo?
cc: @mai93 It looks like you added this flag, can you take an initial look at it?
It's not clear if this is a cquery problem or an objective c rules problem, or in the actual implementation of the flag.
/cc @katre I noticed both actions tried to generate the output under bazel-out/darwin-opt-exec-2B5CBBC6, however they are actually for different configurations (host vs target). How does the 2B5CBBC6 get generated, does it take the action envs into consideration?
Host config would always use "darwin-opt-host", if the output directory says "exec" then it's an exec transition. There are cases where distinct execution configurations use the same output path (the hex tag is just a hash of the execution platform).
Is there a reason why SymlinkTree actions aren't sharable?
Hmm, it sounds weird the --host_action_env flag will cause an exec transition.
Is there a reason why SymlinkTree actions aren't sharable?
I would expect there to be only one SymlinkTree action for each binary, but here Bazel seems to generate two for different configurations. I have little knowledge about config transition, not sure how it's affected by the --host_action_env flag.
@mai93 No one seems to know which team this really belongs to. Can you offer an assessment.
@martinxsliu If you set both --action_env and --host_action_env to the same things, does it work? Is there a small repro?
@martinxsliu If you set both --action_env and --host_action_env to the same things, does it work? Is there a small repro?
It doesn't work. The repo case is in the PR description, I can repro this on my macbook.
@mai93, can you please update this issue with any debugging steps you've done and the root cause you've determined?
As @katre suggested, I needed to also pass the value of host_action_env to hostActionEnvironment attribute of the host options in CoreOptions.getHost.
I guess not setting this attribute caused the env var NAME not to propagate to the second execution configuration during execution transition and that is why we had two different ones.
I also think that the following dependency is missing in //foo:go_default_test that needs to be added for the repro to work after submitting the change.
deps = ["@com_github_golang_mock//gomock:go_default_library"],
@mai93 Thanks a lot for fixing this!
Most helpful comment
As @katre suggested, I needed to also pass the value of
host_action_envtohostActionEnvironmentattribute of the host options inCoreOptions.getHost.I guess not setting this attribute caused the env var
NAMEnot to propagate to the second execution configuration during execution transition and that is why we had two different ones.I also think that the following dependency is missing in //foo:go_default_test that needs to be added for the repro to work after submitting the change.
deps = ["@com_github_golang_mock//gomock:go_default_library"],