jheaff1

Could you share the content of your BUILD file(s) here so i can take a look?

Could you try wrapping the output of the genrule in a cc_import rule?

Does the following work? ```python "VERSION_HEADER_LOCATION" : "$(dirname $(execpath :generate_version))" ``` And change the `deps` attribute to [`build_data`](https://bazelbuild.github.io/rules_foreign_cc/main/make.html#make-build_data): ```python build_data = [":generate_version"] ```

Ah ok, it seems like your only option is to use the `deps` attribute, which requires a `CcInfo` provider, which cc_import or cc_library should provide. not sure why the code...

Perhaps try: ``` env = { "VERSION_HEADER_LOCATION" : “$EXT_BUILD_DEPS/version_header“ }, ```

Will this be of any use? https://docs.bazel.build/versions/main/command-line-reference.html#flag--incompatible_strict_action_env

While not ideal, my method is to view the build log generated by rules_foreign_cc while it is building. You can find the log in the bowels of the Bazel build...

> Same need here. The trick works: a `CMake.log` file is produced afterwards, but only afterwards the build is over. Since it fails in my case, and the build takes...

It’s strange that cross compiling doesn’t work for you; I can cross compile the `zlib` [example](https://github.com/bazelbuild/rules_foreign_cc/blob/main/examples/third_party/zlib/BUILD.zlib.bazel) for Android using the `cmake` rule just fine.

Ah I see. Perhaps once this issue is resolved, the CI of this repo should utilise the zig toolchain to cross compile libjpeg_turbo, which relies on `${CMAKE_SYSTEM_PROCESSOR}`