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

Support Clang Modules / Frameworks ( swift ) #2272

Closed
alloy opened this Issue Jun 25, 2014 · 28 comments

Comments

Projects
None yet
@alloy
Member

alloy commented Jun 25, 2014

Current state of ways how libraries can be packaged. aka Swift Libraries

There are basically three ways, the newer ones need a bit more looking into to see if assertions are correct and/or if we’re missing more features they provide:

  • Static libraries: separate headers and resources files, needs header search paths through e.g. xcconfig. Available on all OS versions.
  • Clang Modules: separate headers and resources files, headers are made available through the module map. Available on iOS 7 and OS X 10.9 for system libraries (although they presumably also work for third-party code [proof needed]) and for all libraries on iOS 8 and OSX 10.10.
  • (Dynamic) Frameworks: all files bundled in framework bundle, headers are made available through framework search paths and, presumably, nowadays also through Clang Modules. Available on iOS 8 (https://pbs.twimg.com/media/Bu8HkTOIIAEVgeJ.png:large) and all OS X versions (keeping in mind that the Clang Modules part only applies to 10.9+).

Goal

Eventually all libs should use Dynamic Frameworks and Clang Modules.

  • Dynamic Frameworks are necessary for e.g. Xcode Playgrounds, to be able to dynamically inject code and make it available to the Playground.
  • Standardising on this means that we can eventually converge on simply letting Xcode projects define how the individual frameworks should be build in one place and CocoaPods can simply leave those details up to Xcode to deal with. (E.g. dealing with header namespacing, resource bundling, etc becomes much simpler for CocoaPods.)
  • This standardization is beneficial to the whole community, not just CocoaPods users.

Transition phase

As we still need to support older deployment targets, we cannot simply switch everything over to the new ways of doing things. As such, we need to come up with a way to start implementing and using the new ways, while still supporting static libraries. The current roadmap for this looks like so:

  1. Maintain the current Pods directory layout and use of xcconfigs.
  2. In addition, generate Clang Modules maps, if needed.
  3. Make it possible to generate Dynamic Framework targets from CocoaPods libs.

This would then allow the following deployment target scenarios:

  • <= iOS 7 and OS X 10.9:
    • Produce static libs for individual libs
    • Produce a static aggregate lib (libPods.a)
    • Use xcconfigs for header search paths and linking.
  • iOS 8 and OS X 10.10:
    • Produce Dynamic Frameworks for individual libs
    • Produce a Framework Target for the aggregation (Pods.framework), which will be used as Target Dependency in the host library
    • Use Clang Modules maps for headers and linking.
    • Once we've reached this phase, it would make it easy to use Dynamic Frameworks for all OS X deployment targets, as OS X has always supported this.

With these scenarios, it should already be possible to make use of new platform features that require Dynamic Frameworks, such as importing into Swift and Xcode Playgrounds.

@alloy

This comment has been minimized.

Show comment
Hide comment
@alloy

alloy Jun 25, 2014

Member

Please suggest fixes/improvements to the roadmap as it is and links to relevant documentation.

Member

alloy commented Jun 25, 2014

Please suggest fixes/improvements to the roadmap as it is and links to relevant documentation.

@alloy

This comment has been minimized.

Show comment
Hide comment
@alloy

alloy Jun 25, 2014

Member

This is basically the outcome of a recent high-level Google Hangout we did. We’ll be having a second round in the near future, please watch this thread for a date+time if you’re interested in contributing knowledge about these discussed issues.

Member

alloy commented Jun 25, 2014

This is basically the outcome of a recent high-level Google Hangout we did. We’ll be having a second round in the near future, please watch this thread for a date+time if you’re interested in contributing knowledge about these discussed issues.

@AlexDenisov

This comment has been minimized.

Show comment
Hide comment
@AlexDenisov

AlexDenisov Jun 25, 2014

Would be great to distribute the frameworks, not a source code. In this case end user will not need to compile the same library each time he builds project (after cleaning, of course) and for each project.

CocoaPods is like Make/CMake, but with own ruby-syntax and with ruby-approach (source code copy-pasting), which isn't the best approach for compiled language, so it's a very good step forward.

AlexDenisov commented Jun 25, 2014

Would be great to distribute the frameworks, not a source code. In this case end user will not need to compile the same library each time he builds project (after cleaning, of course) and for each project.

CocoaPods is like Make/CMake, but with own ruby-syntax and with ruby-approach (source code copy-pasting), which isn't the best approach for compiled language, so it's a very good step forward.

@kylef

This comment has been minimized.

Show comment
Hide comment
@kylef

kylef Jun 25, 2014

Contributor

@AlexDenisov cocoapods-packager plugin is aimed to do just that 👍.

Contributor

kylef commented Jun 25, 2014

@AlexDenisov cocoapods-packager plugin is aimed to do just that 👍.

@swizzlr

This comment has been minimized.

Show comment
Hide comment
@swizzlr

swizzlr Jun 25, 2014

Contributor

Great, so we make an enormous if statement? This can't be too hard to add 8 support?

Contributor

swizzlr commented Jun 25, 2014

Great, so we make an enormous if statement? This can't be too hard to add 8 support?

@danthorpe

This comment has been minimized.

Show comment
Hide comment
@danthorpe

danthorpe Jul 7, 2014

Contributor

Hi, so, given the proposed roadmap, does this mean that the following (what I expect will be quite common) scenario will work...

Given iOS 8, and a project with an application target (and possibly extensions), which depends an internal Framework. Where both the application and framework also depend on the same Pods (or a mixture with some overlap). The potential problem I'm thinking of will be duplicate symbols in the linker stage. Will this be avoided by use of the Dynamic Framework for the aggregate library? Given that Cocoapods would presumably create Pods-MyTarget-AggregateFramework and Pods-MyFramework-AggregateFramework - both of which would include the same libraries?

Contributor

danthorpe commented Jul 7, 2014

Hi, so, given the proposed roadmap, does this mean that the following (what I expect will be quite common) scenario will work...

Given iOS 8, and a project with an application target (and possibly extensions), which depends an internal Framework. Where both the application and framework also depend on the same Pods (or a mixture with some overlap). The potential problem I'm thinking of will be duplicate symbols in the linker stage. Will this be avoided by use of the Dynamic Framework for the aggregate library? Given that Cocoapods would presumably create Pods-MyTarget-AggregateFramework and Pods-MyFramework-AggregateFramework - both of which would include the same libraries?

This was referenced Jul 8, 2014

@kylef kylef referenced this issue Jul 18, 2014

Closed

Support creating framework targets #164

2 of 2 tasks complete
@seivan

This comment has been minimized.

Show comment
Hide comment
@seivan

seivan Jul 20, 2014

Contributor

Out of curiosity how hard is it to leave the creation of the "new" dynamic frameworks on pod install, instead of being supplied by the pods themselves?

That way all existing pods that distribute source code could automatically be name-spaced dynamically on installation instead of all of them being updated to distribute frameworks on their own.

This would also help in instances where you need to support both Mac OS and iOS targets. Instead of having to create a new framework for each, Cocoapods take cares of that depending on what target you have set up for.

This might be what Alloy meant with the third point.
Make it possible to generate Dynamic Framework targets from CocoaPods libs.

Contributor

seivan commented Jul 20, 2014

Out of curiosity how hard is it to leave the creation of the "new" dynamic frameworks on pod install, instead of being supplied by the pods themselves?

That way all existing pods that distribute source code could automatically be name-spaced dynamically on installation instead of all of them being updated to distribute frameworks on their own.

This would also help in instances where you need to support both Mac OS and iOS targets. Instead of having to create a new framework for each, Cocoapods take cares of that depending on what target you have set up for.

This might be what Alloy meant with the third point.
Make it possible to generate Dynamic Framework targets from CocoaPods libs.

@mrackwitz

This comment has been minimized.

Show comment
Hide comment
@mrackwitz

mrackwitz Jul 20, 2014

Member

@seivan

Out of curiosity how hard is it to leave the creation of the "new" dynamic frameworks on pod install, instead of being supplied by the pods themselves?

The pods would provide neither static libraries nor frameworks by themselfs. You can change for your pod, how you build it locally to test it. But this wouldn't change, how pod install integrates them. Currently it builds static libraries from all pods. This will change in future.

That way all existing pods that distribute source code could automatically be name-spaced dynamically on installation instead of all of them being updated to distribute frameworks on their own.

This will happen anyway. 😉

This would also help in instances where you need to support both Mac OS and iOS targets. Instead of having to create a new framework for each, Cocoapods take cares of that depending on what target you have set up for.

This happens already.

Member

mrackwitz commented Jul 20, 2014

@seivan

Out of curiosity how hard is it to leave the creation of the "new" dynamic frameworks on pod install, instead of being supplied by the pods themselves?

The pods would provide neither static libraries nor frameworks by themselfs. You can change for your pod, how you build it locally to test it. But this wouldn't change, how pod install integrates them. Currently it builds static libraries from all pods. This will change in future.

That way all existing pods that distribute source code could automatically be name-spaced dynamically on installation instead of all of them being updated to distribute frameworks on their own.

This will happen anyway. 😉

This would also help in instances where you need to support both Mac OS and iOS targets. Instead of having to create a new framework for each, Cocoapods take cares of that depending on what target you have set up for.

This happens already.

@seivan

This comment has been minimized.

Show comment
Hide comment
@seivan

seivan Jul 20, 2014

Contributor

@mrackwitz Awesomo!
I prefer to supply source code and have Cocoapods integrate them however it wants. Though if you want to take advantage of namespaces (and avoid prefixing) you'd need to have them as their own Frameworks. Glad to hear Cocoapods takes care of it on its own.

Contributor

seivan commented Jul 20, 2014

@mrackwitz Awesomo!
I prefer to supply source code and have Cocoapods integrate them however it wants. Though if you want to take advantage of namespaces (and avoid prefixing) you'd need to have them as their own Frameworks. Glad to hear Cocoapods takes care of it on its own.

@ketzusaka

This comment has been minimized.

Show comment
Hide comment
@ketzusaka

ketzusaka Sep 15, 2014

If individual libs are created using a static library for iOS 8, does that mean we won't be able to include swift code until they are compilable into static libraries?

ketzusaka commented Sep 15, 2014

If individual libs are created using a static library for iOS 8, does that mean we won't be able to include swift code until they are compilable into static libraries?

@segiddins

This comment has been minimized.

Show comment
Hide comment
@segiddins

segiddins Sep 15, 2014

Member

We are working on native Framework support, which will allow the inclusion of swift code.

Member

segiddins commented Sep 15, 2014

We are working on native Framework support, which will allow the inclusion of swift code.

@ketzusaka

This comment has been minimized.

Show comment
Hide comment
@ketzusaka

ketzusaka Sep 17, 2014

@segiddins For iOS 8? The roadmap above said that was targeted for iOS9

ketzusaka commented Sep 17, 2014

@segiddins For iOS 8? The roadmap above said that was targeted for iOS9

@robertjpayne

This comment has been minimized.

Show comment
Hide comment
@robertjpayne

robertjpayne Sep 18, 2014

FWIW static libraries are possible from Xcode right now that include Swift code. It's not clean and it's a pain to make it work but I'm working towards cleaning it up: SnapKit/SnapKit#12.

robertjpayne commented Sep 18, 2014

FWIW static libraries are possible from Xcode right now that include Swift code. It's not clean and it's a pain to make it work but I'm working towards cleaning it up: SnapKit/SnapKit#12.

@mrackwitz

This comment has been minimized.

Show comment
Hide comment
@mrackwitz

mrackwitz Sep 18, 2014

Member

@robertjpayne: Thanks for sharing your research results. I will take some time very soon and update the above described roadmap to represent our latest efforts.

Member

mrackwitz commented Sep 18, 2014

@robertjpayne: Thanks for sharing your research results. I will take some time very soon and update the above described roadmap to represent our latest efforts.

@robertjpayne

This comment has been minimized.

Show comment
Hide comment
@robertjpayne

robertjpayne Sep 19, 2014

Here's a gist outlining how to compile a static library for swift. It's a small ruby script that takes care of walking through the appropriate steps.

It's a bit primitive, it only takes a single swift file as input and does not support linking libraries or frameworks outside the base SDK.

https://gist.github.com/robertjpayne/5dacd4d31299165c28ab

It generates the .a and the appropriate module files so code completion and auto linking play nice.

robertjpayne commented Sep 19, 2014

Here's a gist outlining how to compile a static library for swift. It's a small ruby script that takes care of walking through the appropriate steps.

It's a bit primitive, it only takes a single swift file as input and does not support linking libraries or frameworks outside the base SDK.

https://gist.github.com/robertjpayne/5dacd4d31299165c28ab

It generates the .a and the appropriate module files so code completion and auto linking play nice.

@flovilmart

This comment has been minimized.

Show comment
Hide comment
@flovilmart

flovilmart Oct 20, 2014

I'm really interested in helping there as the linking mechanism causes several problems when it comes to generate a framework.

Let's say I want to build a framework and share it with my Today Extension and .app. So far, with the pods all objects are statically linked in each framework, so at runtime, it crashes as symbols are duplicated.

That shouldn't be 'too' long to switch from 'Static Lib' target to 'Embedded Framework Target' as a first step. (an extra info.plist, some build settings)

I may be wrong here...

Anyway, if anyone's working on that right now, I'd love to jump on the boat as it's heavily blocking me now

flovilmart commented Oct 20, 2014

I'm really interested in helping there as the linking mechanism causes several problems when it comes to generate a framework.

Let's say I want to build a framework and share it with my Today Extension and .app. So far, with the pods all objects are statically linked in each framework, so at runtime, it crashes as symbols are duplicated.

That shouldn't be 'too' long to switch from 'Static Lib' target to 'Embedded Framework Target' as a first step. (an extra info.plist, some build settings)

I may be wrong here...

Anyway, if anyone's working on that right now, I'd love to jump on the boat as it's heavily blocking me now

@orta

This comment has been minimized.

Show comment
Hide comment
@orta

orta Oct 20, 2014

Member

There's been a lot of work done by @mrackwitz which does nearly everything needed for Swift CocoaPods. The main holdup is just the core team's time to get it integrated and very well tested. I won't give dates, but I'd say it's pretty soon. If you're interested in helping out, he may have ideas there.

Member

orta commented Oct 20, 2014

There's been a lot of work done by @mrackwitz which does nearly everything needed for Swift CocoaPods. The main holdup is just the core team's time to get it integrated and very well tested. I won't give dates, but I'd say it's pretty soon. If you're interested in helping out, he may have ideas there.

@ValCapri

This comment has been minimized.

Show comment
Hide comment
@ValCapri

ValCapri Oct 20, 2014

Thank you for the update. It will be cool to re-create a "swift" branch, merge the work done by @mrackwitz and start beta testing. Swift is now very near 1.0 final (if it isn't) as Yosemite is available and iOS 8.1 will be today (with final of Xcode 6.1). It will be very appreciate if the core team can update this issue as the integration progress.

ValCapri commented Oct 20, 2014

Thank you for the update. It will be cool to re-create a "swift" branch, merge the work done by @mrackwitz and start beta testing. Swift is now very near 1.0 final (if it isn't) as Yosemite is available and iOS 8.1 will be today (with final of Xcode 6.1). It will be very appreciate if the core team can update this issue as the integration progress.

@flovilmart

This comment has been minimized.

Show comment
Hide comment
@flovilmart

flovilmart Oct 20, 2014

Swift is 1.1 with Xcode 6.1, lots of changes there...

flovilmart commented Oct 20, 2014

Swift is 1.1 with Xcode 6.1, lots of changes there...

@segiddins

This comment has been minimized.

Show comment
Hide comment
@segiddins

segiddins Oct 20, 2014

Member

Guys, we're working on this as fast as we can. To see updates on the incredible work Marius is doing, follow those individual pull requests.

-Samuel E. Giddins

On Oct 20, 2014, at 8:34 AM, Florent Vilmart notifications@github.com wrote:

Swift is 1.1 with Xcode 6.1, lots of changes there...


Reply to this email directly or view it on GitHub.=

Member

segiddins commented Oct 20, 2014

Guys, we're working on this as fast as we can. To see updates on the incredible work Marius is doing, follow those individual pull requests.

-Samuel E. Giddins

On Oct 20, 2014, at 8:34 AM, Florent Vilmart notifications@github.com wrote:

Swift is 1.1 with Xcode 6.1, lots of changes there...


Reply to this email directly or view it on GitHub.=

@flovilmart

This comment has been minimized.

Show comment
Hide comment
@flovilmart

flovilmart Oct 20, 2014

Yeah @mrackwitz is killing it like a chef! I you need anything to help, i'll be pleased to help!

flovilmart commented Oct 20, 2014

Yeah @mrackwitz is killing it like a chef! I you need anything to help, i'll be pleased to help!

@ValCapri

This comment has been minimized.

Show comment
Hide comment
@ValCapri

ValCapri Oct 20, 2014

Thank you @flovilmart and @segiddins for the info. Why not link their's pull requests here and update the first post.
I often keep an eye on this issue and #2222 to track change.

ValCapri commented Oct 20, 2014

Thank you @flovilmart and @segiddins for the info. Why not link their's pull requests here and update the first post.
I often keep an eye on this issue and #2222 to track change.

@ValCapri

This comment has been minimized.

Show comment
Hide comment
@ValCapri

ValCapri Oct 21, 2014

I just saw that the work done by @mrackwitz is now merged in master branch. Thanks to the core team and @mrackwitz..#2461 is now closed.

ValCapri commented Oct 21, 2014

I just saw that the work done by @mrackwitz is now merged in master branch. Thanks to the core team and @mrackwitz..#2461 is now closed.

@flovilmart

This comment has been minimized.

Show comment
Hide comment
@flovilmart

flovilmart Oct 21, 2014

Quick question, why generate only 1 framework will all dependencies when it makes more sense to generate 1 framework per dependency?

flovilmart commented Oct 21, 2014

Quick question, why generate only 1 framework will all dependencies when it makes more sense to generate 1 framework per dependency?

@mrackwitz

This comment has been minimized.

Show comment
Hide comment
@mrackwitz

mrackwitz Oct 22, 2014

Member

@ValCapri: #2461 was only the tip of the iceberg, there is a lot more to come, but there are quite some changes involved around our various projects.

@flovilmart:

why generate only 1 framework will all dependencies when it makes more sense to generate 1 framework per dependency?

That's not the plan anymore. We will build a separate framework for each dependency and embed them all one by one in the app bundle, without an actual umbrella framework artifact. I've updated the issue description to reflect that.

Here is a quick summary:

This would then allow the following deployment target scenarios:

  • <= iOS 7 and OS X 10.9:
    • Produce static libs for individual libs
    • Produce a static aggregate lib (libPods.a)
    • Use xcconfigs for header search paths and linking.
  • iOS 8 and OS X 10.10:
    • Produce Dynamic Frameworks for individual libs
    • Produce a Framework Target for the aggregation (Pods.framework), which will be used as Target >Dependency in the host library
    • Use Clang Modules maps for headers and linking.
    • Once we've reached this phase, it would make it easy to use Dynamic Frameworks for all OS X deployment targets, as OS X has always supported this.
Member

mrackwitz commented Oct 22, 2014

@ValCapri: #2461 was only the tip of the iceberg, there is a lot more to come, but there are quite some changes involved around our various projects.

@flovilmart:

why generate only 1 framework will all dependencies when it makes more sense to generate 1 framework per dependency?

That's not the plan anymore. We will build a separate framework for each dependency and embed them all one by one in the app bundle, without an actual umbrella framework artifact. I've updated the issue description to reflect that.

Here is a quick summary:

This would then allow the following deployment target scenarios:

  • <= iOS 7 and OS X 10.9:
    • Produce static libs for individual libs
    • Produce a static aggregate lib (libPods.a)
    • Use xcconfigs for header search paths and linking.
  • iOS 8 and OS X 10.10:
    • Produce Dynamic Frameworks for individual libs
    • Produce a Framework Target for the aggregation (Pods.framework), which will be used as Target >Dependency in the host library
    • Use Clang Modules maps for headers and linking.
    • Once we've reached this phase, it would make it easy to use Dynamic Frameworks for all OS X deployment targets, as OS X has always supported this.
@flovilmart

This comment has been minimized.

Show comment
Hide comment
@flovilmart

flovilmart Oct 22, 2014

@mrackwitz Good, that makes sense.
Do you have a task list/ feature set that I can jump on and try to help with?

flovilmart commented Oct 22, 2014

@mrackwitz Good, that makes sense.
Do you have a task list/ feature set that I can jump on and try to help with?

@orta orta changed the title from First phase towards Clang Modules / Frameworks to Support Clang Modules / Frameworks ( swift ) Nov 18, 2014

@mrackwitz

This comment has been minimized.

Show comment
Hide comment
@mrackwitz

mrackwitz Nov 20, 2014

Member

Just for reference here: there is now PR #2835 for this issue.

Member

mrackwitz commented Nov 20, 2014

Just for reference here: there is now PR #2835 for this issue.

@orta

This comment has been minimized.

Show comment
Hide comment
@orta

orta Dec 28, 2014

Member

Closable?

Member

orta commented Dec 28, 2014

Closable?

@segiddins segiddins closed this Dec 28, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment