jheaff1

Given that python toolchains return `PyRuntimeInfo`, see [here](https://github.com/bazelbuild/bazel/blob/394ddb82b311ea7edbe2522736b0b0202903ddb6/tools/python/toolchain.bzl#L75), perhaps all that is needed to to implement a `current_py_toolchain` rule, similar to [these](https://github.com/bazelbuild/rules_foreign_cc/blob/c57b55f2f6207c0c44c2b4a51dc235955d4f47b2/toolchains/toolchains.bzl#L38) , to return `platform_common.TemplateVariables`

Actually perhaps all that is required is for the [`ninja_tool`](https://github.com/bazelbuild/rules_foreign_cc/blob/c57b55f2f6207c0c44c2b4a51dc235955d4f47b2/foreign_cc/built_tools/ninja_build.bzl#L29) rule to include `@bazel_tools//python:toolchain_type` In the list of toolchains and to extract the path to the python interpreter using `ctx.toolchains[@bazel_tools//python:toolchain_type].py3_runtime.interpreter_path`

This was resolved in #935

FYI I’ve started working on a rule set like bazel_rules_qt that builds qt from source. https://github.com/jheaff1/rules_qt/tree/build_qt_on_linux It’s still very much a work in progress

I’ve built Qt from source using Bazel and was in the process of making a rule set for it but sadly I don’t have time to work on it anymore...

Aside from aqt, one could use this script to install qt without user interaction: https://github.com/qbs/qbs/blob/master/scripts/install-qt.sh

@CareF To workaround the issue you could wrap the toolchain executables in a script that prepends the path with `EXT_BUILD_ROOT`, which is set by rules_foreign_cc. An example of this is...

Yep glad to see it’s in Bazel 6.0!

Is there any timescale on when this support would be added?

I’m unsure why dependencies are built twice. I’m not opposed to runnable_binary being reworked to avoid undesired behaviour