-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Inherit exec_group setting from build actions when selecting executable #21641
Comments
I don't fully understand what you expect to happen here: execution platforms are chosen before actions are defined, and so cannot inherit from the action. The correct flow is to first define execution groups, then use those execution groups when defining actions.
Note that you have four execution groups defined here, I expect that you actually want the
(Or using You may also be interested in automatic execution groups, which lets you avoid manually defining the groups and just lets bazel pick the right execution group for each toolchain you require. Let me know if this helps you out, or please let me know what part of your problem I have misunderstood. |
Hi, Thank you for your reply!
After understood this and how I can affect the execution platform by the rule, I could find a solution to my problem.
where so
and The AEGs looks great, I will check that when we start using Bazel 7+. I think my question has been answered and got a solution, so the issue can be closed. |
Glad this was useful! It's hard for me to figure out where to update documentation, because I am too familiar with the systems involved. Can you think of anywhere our docs on execution groups (or actions, or etc) can be improved that would have helped you sooner? Closing since the issue is resolved but if you do have any doc suggestions I'll fork a new issue for them (or you can create a new issue and tag me on it). |
Description of the feature request:
Hi,
In our team we are using tools to generate intermediate artifacts, which are used by C++ build and link actions afterwards. These tools have different binaries on different platforms, they are compatible with the platform where they were built and usually with the next major release platform, and generate the same outputs. When it comes to the cross-compilation, we need to make sure that we select the proper binary which is compatible with the execution platform, otherwise it might result an error. We encountered an issue during cross-compilation on rhel8 from a rhel7 host, when a local build action, defined by using the no-remote-exec tag, selected the rhel8 compatible binary and tried to run it on the rhel7 host, but failed. Remote actions run fine.
We'd like to have a feature which allows the executable tools to inherit the execution group setting from their related build actions.
Which category does this issue belong to?
Configurability, Local Execution, Remote Execution
What underlying problem are you trying to solve with this feature?
The executable rule attribute when using
cfg="exec"
doesn't inherit the execution group from the related build action, e.g.ctx.actions.run()
., when the rhel8
exec_group
is set, then I would expect that the tool selects the rhel8 compatible binary.The executable rule attribute when using
cfg="target"
doesn't consider the tags when selecting the tool binary.when the
exec_group
is set to host at the build action or having any no-remoteexecution_requirement
, the tool binary will be compatible with the target platform. This might be fine due to the definition of target platform.Specifying
exec_compatible_with
at the rule helps when usingcfg="exec"
, however it doesn't support the multi-platform build well because the attribute is non-configurable.Which operating system are you running Bazel on?
RHEL7
What is the output of
bazel info release
?release 6.0.0 (@06deebfb5b73f848de5a0ea0e00fcfaa26788d1f)
If
bazel info release
returnsdevelopment version
or(@non-git)
, tell us how you built Bazel.We build Bazel from source by using an older release, we patch the source code when we really need to.
https://bazel.build/install/compile-source#build-bazel-using-bazel
What's the output of
git remote get-url origin; git rev-parse HEAD
?No response
Have you found anything relevant by searching the web?
https://bazel.build/extending/platforms
https://bazel.build/extending/exec-groups#platform-execution-properties
I didn't find similar use-case with cross-compilation including local only actions yet.
Any other information, logs, or outputs that you want to share?
I have a personal repository which might help to reproduce the problem and check the platform, constraint and rule implementation. Please set the .rc file accordingly.
https://github.com/spektrof/bazel_crossbuild/tree/main
How did I detect the problem?
We were setting both
--platforms
and--host_platform
to the target platform, didn't use anyexec_group
orexec_compatible_with
attribute, this case we didn't even setcfg
for the attribute. When I started the cross-compilation on rhel8 from rhel7 host, the tool path has been resolved to the rhel8 compatible binary what it tried to run on rhel7 and failed.bazel test :test_group1 --config rhel8_host --config rhel8 --config remote
What else did I try?
I tried to set
exec_groups
for rule withconfig.exec("target")
but I couldn't make it work since it should be non-configurable and don't know how to consider tags there.I tried to check the implementation of
FilesToRunProvider
but as far as I saw the executable path selection is separated from execution group, defined by the build action.I was wondering whether there is a problem in the platform, constraint or rule implementation.
Do you expect these actions to run only locally?
Do you recommend to implement a toolchain for the tool instead?
Thank you very much in advance!
The text was updated successfully, but these errors were encountered: