--run_under flag not working for macos_application

[iphydf]

E.g.: bazel run -c dbg --run_under=lldb //examples/macos/HelloWorld

Output:

(lldb) target create ".../execroot/build_bazel_rules_apple/bazel-out/darwin-dbg/bin/examples/macos/HelloWorld/HelloWorld"
error: '.../execroot/build_bazel_rules_apple/bazel-out/darwin-dbg/bin/examples/macos/HelloWorld/HelloWorld' doesn't contain any 'host' platform architectures: x86_64h, x86_64, i386, x86_64

[keith]

The underlying file here is actually a text file template that runs the underlying app that was built https://github.com/bazelbuild/rules_apple/blob/master/apple/internal/templates/macos.template.sh

I think an alternative approach to having debugging work with bazel run would be to pass some special argument like --attach-lldb on run, and handle that in the macOS runner template

[jfirebaugh]

That would make it incompatible with debugging in VSCode using a plugin like CodeLLDB.

Is there some reason the macos_application rule can't provide a FilesToRunProvider whose executable points to an actual MachO binary?

[keith]

currently when you build the macos_application you either end up with a zip or a .app directory, the script is what normalizes that and runs the binary. maybe the binary could be returned directly when outputting tree artifacts only though.

[jfirebaugh]

Discussion here, but the gist of it is this probably isn't currently possible because there's no way within Starlark to construct a File that refers to a child of a tree artifact, such that that value could be used in

    return DefaultInfo(
        ...,
        executable = executable,
    )

[keith]

is there any flexibility in the lldb use case, for example of we could use --run_under="USE_LLDB=true" we could make the wrapper script support that case