Keith Smiley

Does `PRODUCT_NAME` end up being correct for your `swift_library`'s `module_name`? or if you check the produced .ipa and see the derived value in the Info.plist is it correct?

That issue is different, you can see the details on why that attribute isn't supported here https://github.com/bazelbuild/rules_apple/blob/master/doc/common_info.md#variable-substitution you'll have to replace it manually with your module's name

👋 at Lyft we're using `rules_python` for a lot of tools (but we don't ship python in general with bazel). We're totally happy to contribute here! We're very excited to...

It seems like something must be messed up in your local environment, maybe try a `bazel clean --expunge` and try again? Otherwise can you provide a repro case?

Fixed by https://github.com/bazelbuild/rules_swift/pull/916, thanks for the report. In my testing I had to do a `bazel clean --expunge` after this update, but then it worked, i guess the old artifact...

It seems like something is up with your Xcode build: ``` :0: warning: using sysroot for 'MacOSX' but targeting 'iPhone' ``` once you resolve this warning I imagine you'll get...

I believe this is expected, this mirrors the behavior of defining `copts` on targets as well I think? For example if you have: ``` cc_library( name = "counter", srcs =...

Related tests which current encode the behavior I'm describing https://github.com/bazelbuild/rules_apple/pull/868

xcode uses an internal version of this tool, so they sidestep this issue, their implementation must have more knowledge of platform specifics, swift-stdlib-tool entirely relies on the rpaths, which are...

https://github.com/bazelbuild/rules_apple/pull/1032 ?