Skip to content

Enable swift module interfaces if the package author enables library evolution via unsafe flags #3528

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

Conversation

abertelrud
Copy link
Contributor

Enable swift module interfaces for targets that are compiled with enable-library-evolution. This supports the intent of building a module that way.

Motivation:

There isn't currently a way for package authors to enable library evolution or module interfaces from the package manifest. They can pass -enable-library-evolution in their unsafe flags, but because -emit-module-interface requires a path parameter, it isn't something that can be set in the manifest.

This change enables swift module interfaces when a library does specify -enable-library-evolution in its unsafe flags, supporting the semantic intent of providing that flag.

This is useful in the general case, but is most immediately needed to generate .swiftinterface files for #3431.

Modifications:

  • modify the build plan to pass -emit-module-interface when -enable-library-evolution is specified
  • still honor the old swift-build flag -emit-parseable-module-interfaces, though this is next to useless now because it applies across-the-board, even when library evolution is not enabled, yielding warnings about how library evolution is required for that flag to function
  • modify the XCBuild PIF generation to set a build setting to achieve the same effect when the xcode build system is used

Result:

  • modules that are built with -enable-library-evolution will also have a parseable module interface generated, which supports the intent of setting that flag

rdar://78773077

…evolution via unsafe flags

There isn't currently a way for package authors to enable library evolution or module interfaces from the package manifest.  They can pass `-enable-library-evolution` in their unsafe flags, but because `-emit-module-interface` requires a path parameter, it isn't something that can be set in the manifest.

This adds a way to infer XCBuild settings based on values set in manifest-declared settings.  The idea is to implement semantics appropriately for each platform based on generalized flags passed from the manifest.

rdar://78773077
@abertelrud
Copy link
Contributor Author

@swift-ci please smoke test

@abertelrud
Copy link
Contributor Author

The Linux build doesn't seem to have gotten as far as SwiftPM. Restarting.

@abertelrud
Copy link
Contributor Author

Actually, that was a macOS build. In any case, restarting.

@abertelrud
Copy link
Contributor Author

@swift-ci please smoke test

@abertelrud
Copy link
Contributor Author

@swift-ci please smoke test linux

@abertelrud
Copy link
Contributor Author

Merging this after discussion with @shahmishal to unblock the compatibility suite testing, since we think the lack of a .swiftinterface is the problem there. Will review the approach with @tomerd and @neonichu in particular afterwards and put up a PR for any refinements.

@abertelrud abertelrud merged commit 374f1ea into swiftlang:main Jun 8, 2021
@abertelrud abertelrud deleted the eng/infer-module-interface-when-building-for-library-evolution branch August 16, 2021 22:27
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.

1 participant