Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a Boolean library_evolution attribute to swift_library #1335

Conversation

brentleyjones
Copy link
Collaborator

Historically, library evolution has been supported by a global flag that Apple framework rules transition on in order to build all dependencies with library evolution enabled. In retrospect, this is wrong; we shouldn't be automatically applying library evolution to the whole subgraph in this way. Instead, the owner of the framework should explicitly specify library evolution on the client-facing modules that make up their SDK.

The goal here is to ensure that framework owners carefully audit their public deps vs. implementation-only private_deps so that the .swiftinterface doesn't attempt to import anything that it shouldn't, especially with Swift 5.7 validating emitted interfaces after compilation by default.

This change only adds the new attribute; the flag is still honored while we have clients and rules_apple depending on it.

PiperOrigin-RevId: 486750877
(cherry picked from commit b9175e6)

Cherry-pick notes: With this change the private swiftinterface is enabled by ctx.attr.library_evolution as well. It can be disabled with features = ["-swift.emit_private_swiftinterface”].

@brentleyjones brentleyjones enabled auto-merge (rebase) October 3, 2024 19:08
brentleyjones referenced this pull request Oct 3, 2024
Historically, library evolution has been supported by a global flag that Apple framework rules transition on in order to build all dependencies with library evolution enabled. In retrospect, this is wrong; we shouldn't be automatically applying library evolution to the whole subgraph in this way. Instead, the owner of the framework should explicitly specify library evolution on the client-facing modules that make up their SDK.

The goal here is to ensure that framework owners carefully audit their public `deps` vs. implementation-only `private_deps` so that the `.swiftinterface` doesn't attempt to import anything that it shouldn't, especially with Swift 5.7 validating emitted interfaces after compilation by default.

This change only adds the new attribute; the flag is still honored while we have clients and rules_apple depending on it.

PiperOrigin-RevId: 486750877
@brentleyjones brentleyjones force-pushed the bj/add-a-boolean-library_evolution-attribute-to-swift_library branch from 8c518e3 to 0843af3 Compare October 3, 2024 19:10
Historically, library evolution has been supported by a global flag that Apple framework rules transition on in order to build all dependencies with library evolution enabled. In retrospect, this is wrong; we shouldn't be automatically applying library evolution to the whole subgraph in this way. Instead, the owner of the framework should explicitly specify library evolution on the client-facing modules that make up their SDK.

The goal here is to ensure that framework owners carefully audit their public `deps` vs. implementation-only `private_deps` so that the `.swiftinterface` doesn't attempt to import anything that it shouldn't, especially with Swift 5.7 validating emitted interfaces after compilation by default.

This change only adds the new attribute; the flag is still honored while we have clients and rules_apple depending on it.

PiperOrigin-RevId: 486750877
(cherry picked from commit b9175e6)

Cherry-pick notes: With this change the private swiftinterface is enabled by `ctx.attr.library_evolution` as well. It can be disabled with `features = ["-swift.emit_private_swiftinterface”]`.

Signed-off-by: Brentley Jones <github@brentleyjones.com>
@brentleyjones brentleyjones force-pushed the bj/add-a-boolean-library_evolution-attribute-to-swift_library branch from 0843af3 to 7e14958 Compare October 3, 2024 19:37
@brentleyjones brentleyjones merged commit 6beacf8 into master Oct 4, 2024
14 checks passed
@brentleyjones brentleyjones deleted the bj/add-a-boolean-library_evolution-attribute-to-swift_library branch October 4, 2024 15:03
@tumata
Copy link

tumata commented Oct 8, 2024

Hi,

I've recently started using Bazel to automate the generation of XCFrameworks for distributing our internal frameworks. While reviewing the documentation on the master branch, I encountered the error: no such attribute 'library_evolution' in 'swift_library' rule when attempting to use the library_evolution parameter.

Now finding this PR from only 4 days ago, it that explains my issue!

From your PR description, it seems that library evolution is enabled by default in the current version 2.1.1. Could you please confirm if that's the case?

Thank you for your help!

@luispadron
Copy link
Contributor

luispadron commented Oct 8, 2024

@tumata this commit hasn't made it into a release yet. You can enable it via --features="swift.enable_library_evolution" on the current releases

@tumata
Copy link

tumata commented Oct 8, 2024

Thanks for your help @luispadron. Where do I add this feature you're mentioning?

Should I add it to my bazel build command?

bazel build //:my_xcframework --features='swift.enable_library_evolution'

Please forgive my ignorance, I'm very fresh with Bazel :)

@luispadron
Copy link
Contributor

Yes, it's a flag, you can read more on it: https://bazel.build/reference/command-line-reference#flag--features

You can also add it to a .bazelrc file so it's always applied, or use the features attribute for specific targets

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants