feat: Adds a test case for using swift-build

[maxwellE]

This new test should be able to build the example project added.

it cannot right now due to errors in rspm around bundle accessors

[cgrindel]

This an unusual example. This is the error that I see:

INFO: Running command line: bazel-bin/external/rules_swift_package_manager~~swift_deps~swiftpkg_swift_build/swbuild.rspm build /Users/chuck/code/cgrindel/rules_swift_package_manager/maxwell_pr/examples/swift_build_example/swift-build-app/swift-build-app.xcodeproj --target swift-build-app
Error communicating with the build service: cannot determine build service executable URL

The command in the do_test is:

"${bazel}" run @swiftpkg_swift_build//:swbuild -- build \
    "${script_dir}/swift-build-app/swift-build-app.xcodeproj" \
    --target swift-build-app

The Bazel build appears to complete successfully. The failure is in the Xcode project build. I do not see any errors related to bundle accessors.

As far as I can tell, rules_swift_package_manager is working properly. If you see something else, please provide more info.

[maxwellE]

I just pushed up d49ceb7 it should show the direct error in RSPM

[cgrindel]

The build graph sees a dependency between the swbuild and the missing resource bundle.

# Dependency path from :swbuild.rspm to the missing resource bundle.
$ bazel query 'somepath(@swiftpkg_swift_build//:swbuild.rspm, @swiftpkg_swift_build//:SWBUniversalPlatform.rspm_resource_bundle)'
@swiftpkg_swift_build//:swbuild.rspm
@swiftpkg_swift_build//:SWBBuildServiceBundle.rspm
@swiftpkg_swift_build//:SWBBuildService.rspm
@swiftpkg_swift_build//:SWBUniversalPlatform.rspm
@swiftpkg_swift_build//:SWBUniversalPlatform.rspm_resource_bundle

When I look in the runfiles for swbuild, I do not see the missing resource bundle:

$ tree /private/var/tmp/_bazel_chuck/bfccfcc5f9ede9c9f6099415961273c1/execroot/_main/bazel-out/darwin_arm64-fastbuild/bin/external/rules_swift_package_manager~~swift_deps~swiftpkg_swift_build/swbuild.rspm.runfiles
/private/var/tmp/_bazel_chuck/bfccfcc5f9ede9c9f6099415961273c1/execroot/_main/bazel-out/darwin_arm64-fastbuild/bin/external/rules_swift_package_manager~~swift_deps~swiftpkg_swift_build/swbuild.rspm.runfiles
├── MANIFEST
├── _main
│   └── external
│       └── rules_swift_package_manager~~swift_deps~swiftpkg_swift_build
│           ├── SWBBuildServiceBundle.rspm -> /private/var/tmp/_bazel_chuck/bfccfcc5f9ede9c9f6099415961273c1/execroot/_main/bazel-out/darwin_arm64-fastbuild/bin/external/rules_swift_package_manager~~swift_deps~swiftpkg_swift_build/SWBBuildServiceBundle.rspm
│           └── swbuild.rspm -> /private/var/tmp/_bazel_chuck/bfccfcc5f9ede9c9f6099415961273c1/execroot/_main/bazel-out/darwin_arm64-fastbuild/bin/external/rules_swift_package_manager~~swift_deps~swiftpkg_swift_build/swbuild.rspm
├── _repo_mapping -> /private/var/tmp/_bazel_chuck/bfccfcc5f9ede9c9f6099415961273c1/execroot/_main/bazel-out/darwin_arm64-fastbuild/bin/external/rules_swift_package_manager~~swift_deps~swiftpkg_swift_build/swbuild.rspm.repo_mapping
└── rules_swift_package_manager~~swift_deps~swiftpkg_swift_build
    ├── SWBBuildServiceBundle.rspm -> /private/var/tmp/_bazel_chuck/bfccfcc5f9ede9c9f6099415961273c1/execroot/_main/bazel-out/darwin_arm64-fastbuild/bin/external/rules_swift_package_manager~~swift_deps~swiftpkg_swift_build/SWBBuildServiceBundle.rspm
    └── swbuild.rspm -> /private/var/tmp/_bazel_chuck/bfccfcc5f9ede9c9f6099415961273c1/execroot/_main/bazel-out/darwin_arm64-fastbuild/bin/external/rules_swift_package_manager~~swift_deps~swiftpkg_swift_build/swbuild.rspm

It looks like the runtime dependencies (e.g., data attribute values) from the swift_library are not being forwarded to the swift_binary.

I suspect that the underlying issue is related to the fact that rules_swift_package_manager generates a swift_binary vs an Apple-specific target (e.g., macos_application or macos_command_line_application). Much of the resource bundle handling logic lives in rules_apple. This is tricky

I have a few suggestions for how to move forward:

1. Debug through rules_swift and trace how/where the resource bundle is not being forwarded.
2. Try patching the resulting BUILD.bazel file for swift-build adding a macos_command_line_application. The resource bundle handling code might just work. (I don't recall how resource bundle handling is implemented in the rules_apple rules.)

If using a rules_apple binary target does work, we should raise the question to the rules_swift and rules_apple maintainers how they think we should proceed. One option would be to move some of the resource bundle handling to rules_swift or a place where rules_swift can leverage it. Another option is to update rules_swift_package_manager to generate Apple-specific targets in addition to the swift_binary targets. However, this is tricky. When should they be generated? Which target should we tell a client to use and in which circumstances?

I hope that this helps. Let me know what you find.

cc: @luispadron @brentleyjones If they have any insights or suggestions for how to proceed.

[maxwellE]

So macos_command_line_application did not work either 92e47dd

Ill have to go into rules_swift to figure this out. Thanks for the detailed reply

[maxwellE]

@cgrindel I added a test here, it does look like those transitive runfiles are being pulled in bazelbuild/rules_swift#1507

Are you thinking of another scenario we need coverage for?

[cgrindel]

@cgrindel I added a test here, it does look like those transitive runfiles are being pulled in bazelbuild/rules_swift#1507

Are you thinking of another scenario we need coverage for?

When I looked in the runfiles for the target, I did not see the transitive resource bundles.

[maxwellE]

@cgrindel I added a test here, it does look like those transitive runfiles are being pulled in bazelbuild/rules_swift#1507
Are you thinking of another scenario we need coverage for?

When I looked in the runfiles for the target, I did not see the transitive resource bundles.

So add yet another layer to this test and make sure that layer's data files also are brought into the swift_binary

[maxwellE]

@cgrindel Does this capture the situation? Or does this test need to be in rules apple?