bazelbuild / rules_apple

Bazel rules to build apps for Apple platforms.
Apache License 2.0
505 stars 260 forks source link

Error: key "darwin_arm64_device" not found in dictionary when trying to build apple_xcframework #1838

Open AttilaTheFun opened 1 year ago

AttilaTheFun commented 1 year ago

I'm trying to build an apple_xcframework from a swift_library target. The swift_library target already builds fine and I can use it in an ios_application without issue.

The xcframework is defined like this:

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

apple_xcframework(
    name = "ViewFoundationUIFramework",
    bundle_id = "com.LoganShire.ViewFoundationUIFramework",
    families_required = {
        "ios": [
            "iphone",
            "ipad",
        ],
    },
    infoplists = [":Info.plist"],
    minimum_os_versions = {
        "ios" : "14.0",
    },
    visibility = ["//visibility:public"],
    deps = [
        ":ViewFoundationUI",
    ],
)

Where ViewFoundationUI is the swift_library.

I'm trying to build it with:

bazel build //Libraries/FoundationUI/ViewFoundationUI:ViewFoundationUIFramework

Which yields the following error:

logan@Logans-MBP Snag % bazel build //Libraries/FoundationUI/ViewFoundationUI:ViewFoundationUIFramework 
INFO: Build options --apple_platform_type and --ios_multi_cpus have changed, discarding analysis cache.
ERROR: /Users/logan/Developer/Swift/Apps/Snag/Libraries/FoundationUI/ViewFoundationUI/BUILD:18:18: in apple_xcframework rule //Libraries/FoundationUI/ViewFoundationUI:ViewFoundationUIFramework: 
Traceback (most recent call last):
        File "/private/var/tmp/_bazel_logan/9c5dc880d421e060978209038345ac60/external/build_bazel_rules_apple/apple/internal/xcframework_rules.bzl", line 506, column 83, in _apple_xcframework_impl
                link_outputs_by_library_identifier = _group_link_outputs_by_library_identifier(
        File "/private/var/tmp/_bazel_logan/9c5dc880d421e060978209038345ac60/external/build_bazel_rules_apple/apple/internal/xcframework_rules.bzl", line 194, column 45, in _group_link_outputs_by_library_identifier
                if swift_support.uses_swift(deps[split_attr_key]):
Error: key "darwin_arm64_device" not found in dictionary
ERROR: /Users/logan/Developer/Swift/Apps/Snag/Libraries/FoundationUI/ViewFoundationUI/BUILD:18:18: Analysis of target '//Libraries/FoundationUI/ViewFoundationUI:ViewFoundationUIFramework' failed
ERROR: Analysis of target '//Libraries/FoundationUI/ViewFoundationUI:ViewFoundationUIFramework' failed; build aborted: 
INFO: Elapsed time: 0.188s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (1 packages loaded, 1495 targets configured)
keith commented 1 year ago

You need the ios key right now, like:

    ios = {
        "simulator": [
            "arm64",
            "x86_64",
        ],
        "device": [
            "arm64",
        ],
    },

If that's the issue we should def improve the error. It's not required for the future and supporting other platforms I guess

AttilaTheFun commented 1 year ago

Hmm @keith so that kinda worked but now it's complaining about transitive deps?

logan@Logans-MBP Snag % bazel build //Libraries/FoundationUI/ViewFoundationUI:ViewFoundationUIFramework                
Starting local Bazel server and connecting to it...
ERROR: /Users/logan/Developer/Swift/Apps/Snag/Libraries/FoundationUI/ViewFoundationUI/BUILD:18:18: in apple_xcframework rule //Libraries/FoundationUI/ViewFoundationUI:ViewFoundationUIFramework: 
Traceback (most recent call last):
        File "/private/var/tmp/_bazel_logan/9c5dc880d421e060978209038345ac60/external/build_bazel_rules_apple/apple/internal/xcframework_rules.bzl", line 668, column 45, in _apple_xcframework_impl
                processor_result = processor.process(
        File "/private/var/tmp/_bazel_logan/9c5dc880d421e060978209038345ac60/external/build_bazel_rules_apple/apple/internal/processor.bzl", line 743, column 36, in _process
                partial_outputs = [partial.call(p) for p in partials]
        File "/private/var/tmp/_bazel_logan/9c5dc880d421e060978209038345ac60/external/bazel_skylib/lib/partial.bzl", line 43, column 28, in _call
                return partial.function(*function_args, **function_kwargs)
        File "/private/var/tmp/_bazel_logan/9c5dc880d421e060978209038345ac60/external/build_bazel_rules_apple/apple/internal/partials/swift_framework.bzl", line 59, column 61, in _swift_framework_partial_impl
                swift_module = swift_info_support.swift_include_info(
        File "/private/var/tmp/_bazel_logan/9c5dc880d421e060978209038345ac60/external/build_bazel_rules_apple/apple/internal/swift_info_support.bzl", line 77, column 17, in _swift_include_info
                fail(
Error in fail: error: Swift third party frameworks expect a single swift_library dependency with no transitive swift_library dependencies.
ERROR: /Users/logan/Developer/Swift/Apps/Snag/Libraries/FoundationUI/ViewFoundationUI/BUILD:18:18: Analysis of target '//Libraries/FoundationUI/ViewFoundationUI:ViewFoundationUIFramework' failed
ERROR: Analysis of target '//Libraries/FoundationUI/ViewFoundationUI:ViewFoundationUIFramework' failed; build aborted: 
INFO: Elapsed time: 6.257s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (81 packages loaded, 2495 targets configured)

I just want to generate a framework from a swift_library target and its transitive dependencies which I can pass to rules_xcodeproj in order to create an xcodeproj that builds the subgraph and can run tests on it. Should I just stick with ios_framework for now? Or is there a better option? My understanding was that Apple was pushing xcframeworks as future because you could just build one for all of their platforms.

keith commented 1 year ago

the problem is a bundled xcframework can only contain a single swiftmodule file, where as in the ios_framework case you're not creating a bundled thing, you're just creating N frameworks, 1 for each swift_library. But really choosing between those is a matter of what you're trying to do with the thing. If it's just for development I would stay away from xcframeworks since they have different behavior since they expect to be distributed as an artifact to other devs (like enabling library evolution)