Require full Xcode installation, not only command line tools

[garymm]

Failure:

ERROR: /private/var/tmp/_bazel_garymm/382171cfa5dea081b89290c512972b49/external/build_bazel_rules_swift_local_config/BUILD:9:22: in xcode_swift_toolchain rule @build_bazel_rules_swift_local_config//:toolchain: 
Traceback (most recent call last):
	File "/private/var/tmp/_bazel_garymm/382171cfa5dea081b89290c512972b49/external/build_bazel_rules_swift/swift/internal/xcode_swift_toolchain.bzl", line 566, column 29, in _xcode_swift_toolchain_impl
		target_triples.parse(cc_toolchain.target_gnu_system_name),
	File "/private/var/tmp/_bazel_garymm/382171cfa5dea081b89290c512972b49/external/build_bazel_rules_swift/swift/internal/target_triples.bzl", line 135, column 28, in _parse
		vendor = components[1],
Error: index out of range (index is 1, but sequence has 1 elements)

Note I also tried has_swift = False, which surprisingly fails with: no such attribute 'has_swift' in 'apple_static_xcframework_import' rule

WORKSPACE.bazel:

http_archive(
    name = "build_bazel_rules_apple",
    sha256 = "90e3b5e8ff942be134e64a83499974203ea64797fd620eddeb71b3a8e1bff681",
    url = "https://github.com/bazelbuild/rules_apple/releases/download/1.1.2/rules_apple.1.1.2.tar.gz",
)

load(
    "@build_bazel_rules_apple//apple:repositories.bzl",
    "apple_rules_dependencies",
)

apple_rules_dependencies()

load(
    "@build_bazel_rules_swift//swift:repositories.bzl",
    "swift_rules_dependencies",
)

swift_rules_dependencies()

load(
    "@build_bazel_rules_swift//swift:extras.bzl",
    "swift_rules_extra_dependencies",
)

swift_rules_extra_dependencies()

load(
    "@build_bazel_apple_support//lib:repositories.bzl",
    "apple_support_dependencies",
)

apple_support_dependencies()

BUILD.bazel:

load(
    "@build_bazel_rules_apple//apple:apple.bzl",
    "apple_static_xcframework_import",
)

apple_static_xcframework_import(
    name = "libmoltenvk_dylib",
    xcframework_imports = glob(["sdk/MoltenVK/MoltenVK.xcframework/**"]),
)

[keith]

what target are you trying to build in the case that you see this? it sounds like you might not have a valid CC target or something

[garymm]

It fails if I just build the apple_static_xcframework_import target shown in the example BUILD.bazel file, or if I build a go_library with this in its cdeps.

[keith]

if you put it in the deps of a macos_command_line_application or something similar does it fail the same way? Building the target directly doesn't really make sense because it doesn't actually have any output until other targets depend on it. In the go case it could be that there needs to be some mappings between bazel's platforms to correctly choose the target

[garymm]

What's a minimal macos_command_line_application I could try? My first attempt failed:

apple_static_xcframework_import(
    name = "libmoltenvk_xcframework",
    xcframework_imports = glob(["sdk/MoltenVK/MoltenVK.xcframework/**"]),
)

macos_command_line_application(
    name = "foo",
    minimum_os_version = "11.0",
    deps = [":libmoltenvk_xcframework"],
)

bazel build //:foo
ERROR: /private/var/tmp/_bazel_garymm/3c8f877283731200e512565647d945ec/external/bazel_tools/tools/objc/BUILD:35:13: in objc_library rule @bazel_tools//tools/objc:dummy_lib: Expected action_config for 'objc++-compile' to be configured
ERROR: /private/var/tmp/_bazel_garymm/3c8f877283731200e512565647d945ec/external/bazel_tools/tools/objc/BUILD:35:13: in objc_library rule @bazel_tools//tools/objc:dummy_lib: 
Traceback (most recent call last):
	File "/virtual_builtins_bzl/common/objc/objc_library.bzl", line 127, column 124, in _objc_library_impl
	File "/virtual_builtins_bzl/common/objc/compilation_support.bzl", line 316, column 50, in _register_compile_and_archive_actions
	File "/virtual_builtins_bzl/common/objc/compilation_support.bzl", line 394, column 66, in _cc_compile_and_link
	File "/virtual_builtins_bzl/common/objc/compilation_support.bzl", line 193, column 29, in _compile
Error in compile: Expected action_config for 'objc++-compile' to be configured

[keith]

Do you have a custom C++ toolchain? If so that could also be the original issue

[garymm]

No I don't.

[keith]

Ok can you upload a sample project so I can debug?

[garymm]

https://github.com/garymm/apple_static_xcframework_import

[keith]

What bazel version are you using? using 5.3.1 seems to work:

% bz version
Bazelisk version: development
Build label: 5.3.1
Build target: bazel-out/darwin_arm64-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Mon Sep 19 17:37:11 2022 (1663609031)
Build timestamp: 1663609031
Build timestamp as int: 1663609031
% bz build ...
INFO: Analyzed 2 targets (0 packages loaded, 0 targets configured).
INFO: Found 2 targets...
INFO: Elapsed time: 0.121s, Critical Path: 0.00s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action

[garymm]

➜  bazel version
Bazelisk version: development
Build label: 5.3.1
Build target: bazel-out/darwin_arm64-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Mon Sep 19 17:37:11 2022 (1663609031)
Build timestamp: 1663609031
Build timestamp as int: 1663609031

Maybe something about my xcode setup then?

[keith]

Ah do you have a full Xcode install? Or just the command line tools? You might need a full install if you only have the command line tools. And I would expect xcode-select -p to show a valid Xcode path

[garymm]

Just the command line tools. Would this be moot if has_swift = False worked?

[keith]

Um, potentially. We don't test / claim to support command line tools only for the Apple rules. You can test rules_apple @ HEAD (which requires bazel 6.x rolling releases) and that attribute will be parsed at least, I'm not sure if it would do what you wanted.

For this case in particular since you're not really using Apple specific things, you could instead use a cc_import and set the static_library to the macOS path specifically ./MoltenVK.xcframework/macos-arm64_x86_64/libMoltenVK.a. That definitely wouldn't work for more complex xcframeworks, but for this one it might, then you would avoid the Apple rules all together

[garymm]

OK, thanks for looking into it. I guess a better error message could have saved us a lot of time here, so maybe consider trying to detect this case and provide a clear error message.

Feel free to close this or use it to track whatever improvements, up to you. Thanks!

[keith]

I think technically we could fix this specific case, the issue is in the C++ toolchain setup in bazel itself for the non-Xcode toolchain, but likely you would hit more issues trying to use the Apple rules which definitely assume a full Xcode installation is available.

For reference this can be reproduced even with Xcode if you force bazel to ignore Xcode with BAZEL_USE_CPP_ONLY_TOOLCHAIN=1 bz build ...

[keith]

You can actually work around this by setting BAZEL_TARGET_SYSTEM=arm64-apple-macosx12.3 (or some similarly formatted triple) in the environment to correctly set the toolchain's triple. Without that bazel sets it to local and then we try to parse it as a triple https://github.com/bazelbuild/bazel/blob/1bf22468ae52a11419e233621e2fa1de3c8a6ac2/tools/cpp/unix_cc_configure.bzl#L528-L533