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

The introduced swift templates caching using precompiled binary helper framework will not work because Swift lacks ABI stability. #309

Closed
eugeneego opened this issue May 20, 2017 · 4 comments

Comments

@eugeneego
Copy link
Contributor

#229 #240
The user can have different Swift compiler version than that was used for compilation of SourceryRuntime.framework.
Currently Swift does not have ABI stability. All frameworks and the swift source code files should be compiled using the same compiler.
Also ABI stability is deferred from Swift 4 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032116.html

@eugeneego eugeneego changed the title The introduced swift templates caching using precompiled binary helper framework will not work because swift lacks ABI stability. The introduced swift templates caching using precompiled binary helper framework will not work because Swift lacks ABI stability. May 20, 2017
@ilyapuchka
Copy link
Collaborator

Hey @eugeneego
Users who are using different version of swift compiler than the one used to build Sourcery binary (since the version with improved caching will be released) can build Sourcery from source code in this case. This will build SourceryRuntime framework with the same swift compiler version.

@eugeneego
Copy link
Contributor Author

@ilyapuchka Sourcery uses CocoaPods for distributing and probably can compile SourceryRuntime framework during project build.

@ilyapuchka
Copy link
Collaborator

Currently with CocoaPods we distribute only release archive, not a source code. So to build runtime framework with CocoaPods will make us probably to include its source code into release archive, so that CocoaPods can use it to build the framework as a post step somehow. Or we will need to switch to distributing the whole source code instead of just release artefacts. But I'm not sure how it will behave in this case. Most likely it will link user project with SourcercyRuntime framework which is not needed at all and will require other hacks to disable that. And I'm not even sure if CocoaPods supports building binaries.

SourceryRuntime framework is used not only by the swift templates but also by Sourcery itself. Sourcery when it compiles swift templates (as a step of rendering) simply copy this framework from its bundle to the build path of templates. To use different version of SourceryFramework in this case we will have to provide additional CLI argument for the path to this binary.

Sounds for me like a lot of work and much more complicated setup comparing with building from source code.

@ilyapuchka
Copy link
Collaborator

I will close this for now, if you will have any further questions or suggestions feel free to reopen it.

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

No branches or pull requests

2 participants