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 support for swift source files #2222

Closed
wants to merge 1 commit into from

Conversation

@kylef
Copy link
Contributor

commented Jun 3, 2014

💥

Incomplete, it adds the files but I think we need to create a module.

  • Support generating frameworks instead of static libraries (this should be done in a different issue/PR)
  • Add support for swift file extension
  • Create bridging headers

  • Decide on the best way to design this as backwards compatible (vague, I know – swizzlr)
@mtitolo

This comment has been minimized.

Copy link
Member

commented Jun 3, 2014

🎉

@kylef kylef referenced this pull request Jun 3, 2014
@swizzlr

This comment has been minimized.

Copy link
Contributor

commented Jun 3, 2014

@kylef mate come down here i got infoz

@orta

This comment has been minimized.

Copy link
Member

commented Jun 3, 2014

👍

@segiddins

This comment has been minimized.

Copy link
Member

commented Jun 3, 2014

Isn't there a comparable change in xcodeproj that we have to make?

@kylef

This comment has been minimized.

Copy link
Contributor Author

commented Jun 3, 2014

I don't think xcodeproj needs to be changed, the CocoaPods use of Xcodeproj needs to be changed. Instead of using static libraries, a framework should be made. There is also a EMBEDDED_CONTENT_CONTAINS_SWIFT compiler flag. I think #2221 should make it work.

@kylef

This comment has been minimized.

Copy link
Contributor Author

commented Jun 3, 2014

Of course, to keep compatibility we need to support both static libraries and frameworks.

@segiddins

This comment has been minimized.

@swizzlr

This comment has been minimized.

Copy link
Contributor

commented Jun 3, 2014

we need to find out if frameworks are supported in iOS backwards

@mtitolo

This comment has been minimized.

Copy link
Member

commented Jun 3, 2014

@segiddins there do not appear to be any new constants added to the .pbxproj that would be relevant to Xcodeproj after some poking around.

@AliSoftware

This comment has been minimized.

Copy link
Contributor

commented Jun 3, 2014

Yeahh man, nice! Can't wait to see this completed! 👍

Oh yes

@swizzlr

This comment has been minimized.

Copy link
Contributor

commented Jun 12, 2014

Okay real talk here we need to think about the architecture going forward.

Swift needs .frameworks. I don't know if that's iOS 7 out the window. I assume it is.

We can do things in two ways:

  • if iOS 8 then build every pod as a framework
    • if we do this then we might as well cut down the Podspec and just directly clone a repo as a submodule and integrate the designated .xcodeproj that produces the framework, leaving CP to manage versioning etc.
  • if Swift then build that Pod as a framework, leaving ObjC ones around as normal
    • but if the Swift pod depends on an ObjC pod we need to generate bridging headers (complexity++)
    • or we can build that pod as a framework and so on

I'm leaning towards the first approach for simplicity. I had a go at it, Xcodeproj supports creating frameworks (undocumented). We need to make it do that, cut out the aggregate link phase and make the pods resources get bundled in the framework.

HOW DO WE FACTOR THE LAST SENTENCE PROPERLY?
HOW DO WE CHECK IF IOS 8?
IS THIS THE RIGHT APPROACH, TO LEAVE IOS 7 PEOPLE BEHIND?

@gamenerds

This comment has been minimized.

Copy link

commented Jun 12, 2014

Forgive my ignorance (I'm not a contributor yet nor understand this on your level), but it seems that leaving iOS 7 behind means Swift CP support being half-helpful (if even) pre-iOS 8 and not fully helpful until at least next April/May when most people start dropping iOS 7 support.

Complexity++ sucks, but building a real iOS 8 app using Swift-only dependencies is currently a fantasy, so we probably just have to work toward assumption that there'll be a lot of Swift/ObjC intermixing. This will probably last for awhile seeing as Swift adoption may not be that fast once the initial excitement comes down and people realize Swift is still kind of raw. Dunno.

It's English - nobody knows how to factor sentences properly.

@mtitolo

This comment has been minimized.

Copy link
Member

commented Jun 12, 2014

Swift needs .frameworks. I don't know if that's iOS 7 out the window. I assume it is.

Swift is backwards compatible with iOS 7. It will not work with Xcode 5. So the discussion is how to support the new changes in Xcode 6/Swift, and still support Xcode 5 for those who can't upgrade.

I've played around with the new frameworks stuff in 6, and most of what CP does can stay the same. We'll just be creating a .framework instead of libPods.a and linking against it instead of adding a Target Dependency. This can be done without the use of a workspace, but I like being able to see the source of code I'm using while still in my project.

We'll still need a Pods.xcodeproj to generate the .framework, we'll still need to reference it in our targets. The rest of the framework discussion should continue in #2221.

@hallas

This comment has been minimized.

Copy link

commented Jun 12, 2014

Cool. Let's get this show on the road !! :)

@swizzlr

This comment has been minimized.

Copy link
Contributor

commented Jun 12, 2014

@gamenerds I didn't say Swift-only – I mean embedded frameworks only. And I meant "how to take that sentence and make a sensible OO solution to requirements expressed within".

@mtitolo This still doesn't address the issue – can we have embedded frameworks in iOS 7?

@neonichu

This comment has been minimized.

Copy link
Member

commented Jun 12, 2014

@swizzlr @mtitolo only thing related to this I could find is this: https://devforums.apple.com/message/977606#977606

So it seems, no is the answer.

@mtitolo

This comment has been minimized.

Copy link
Member

commented Jun 12, 2014

@neonichu @swizzlr sad 🐼. I hadn't actually tried it, but it does look like embedded frameworks won't work on iOS 7.

@neonichu

This comment has been minimized.

Copy link
Member

commented Jun 12, 2014

So, IMHO, in addition to frameworks, CP should also be able to generate a bridging header for all Pods, so that one can properly write Swift apps which support iOS 7.

@swizzlr

This comment has been minimized.

Copy link
Contributor

commented Jun 12, 2014

Can we make a static lib with Swift that's still importable? Somehow generate the mmap?

But that's a question that's quite complex. For now I think we should have the MVP of adding a "Framework mode" which is enabled when using Swift pods or asked for.

@mfrawley

This comment has been minimized.

Copy link

commented Jun 13, 2014

Really eager to see how this turns out, just thought I'd add some useful info for those who don't read compiler docs for fun. The following points only refer to exposing Obj-C modules to Swift / Obj-C code:
To import a module in Objective-C you can use the following syntax since Clang 3.5:

 @import mod.submod

The clang compiler finds these modules via a mod.modulemap file with syntax like this:

module std [system] [extern_c] {
  module complex {
    header "complex.h"
    export *
  }

The clang docs might be a useful basis for discussion for those who haven't read them:
http://clang.llvm.org/docs/Modules.html

This module map functionality was originally intended for exposing Objective-C/C code as modules, to solve some of the horribleness of linking .h files in a backwards compatible way, and it works fine in XCode 5.

As I understand it, a framework can be avoided, as @swizzlr mentioned all you need is a modulemap.

Paths to including this could be (these might be wholly useless suggestions, just being constructive):

Manually creating the module maps

Add a config option like

:module_map_file => 'blah.modulemap'

In this case the module author could specify the location of the module map

or

All module-related config in the Podspec

e.g.

:modules => {
:blah => {:headers => ['blah.h], :export => '*'}
}

To specify all of the available options for the modulemap DSL
This seems much more complex given how much flexibility there is in the modulemaps but it potentially presents a faster route to migrating code as all libs with podspecs can be adapted without any code change in the lib itself). I'm not sure which path is better.

@rjsamson

This comment has been minimized.

Copy link

commented Jun 13, 2014

@swizzlr @mtitolo @neonichu I'm actually using a swift module, as a framework, as part of a swift application that is targeting iOS 7.1, and runs just fine on my 5s running 7.1, so i don't think 7.1 vs 8 is a factor, just xcode 5 vs 6.

@swizzlr

This comment has been minimized.

Copy link
Contributor

commented Jun 13, 2014

@rjsamson That's super encouraging to hear! We need some clarification from Apple on this, for sure.

@mfrawley Bloody excellent investigating. Does anybody want to try doing this with a static lib and handcrafted mmap?

@kylef Do you mind if I edit your original post to add a task list?

@kylef

This comment has been minimized.

Copy link
Contributor Author

commented Jun 13, 2014

@swizzlr Go ahead 👍.

@floere floere referenced this pull request Jun 14, 2014
@alloy

This comment has been minimized.

Copy link
Member

commented Jun 16, 2014

Can we do a google hangout session about this, so I can get up to speed about all this stuff and your thoughts? (Anyone that has info, not necessarily existing CP contributors.)

I have a conference at the end of this week, so I can’t guarantee being up-to-speed before than, therefor I propose Monday the 23rd: http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140623&p1=16, during working hours preferred.

@orta

This comment has been minimized.

Copy link
Member

commented Jun 16, 2014

What about 4pm Amsterdam time, http://everytimezone.com/#2014-6-16,120,cn3 ?

@alloy

This comment has been minimized.

Copy link
Member

commented Jun 16, 2014

Sounds good to me!

@0xced

This comment has been minimized.

Copy link
Contributor

commented Jun 23, 2014

I’m available from 19:00 to 23:00 GMT.

@orta

This comment has been minimized.

@ankurp

This comment has been minimized.

Copy link

commented Jun 29, 2014

So will this be merged to add Swift support?

@swizzlr

This comment has been minimized.

Copy link
Contributor

commented Jun 30, 2014

Way too much work left to do.

@danthorpe

This comment has been minimized.

Copy link
Contributor

commented Jul 6, 2014

Hello, what was the result of the Hangout session?

@kylef

This comment has been minimized.

Copy link
Contributor Author

commented Jul 7, 2014

@danthorpe That's all outlined in #2272.

@kreeger kreeger referenced this pull request Jul 9, 2014
@keith keith referenced this pull request Jul 12, 2014

@CocoaPods CocoaPods locked and limited conversation to collaborators Aug 16, 2014

@segiddins

This comment has been minimized.

Copy link
Member

commented Sep 6, 2014

Create bridging headers

Rather, wouldn't we want to identify (+ create if necessary) the bridging header and import a root header for each pod?

@orta

This comment has been minimized.

Copy link
Member

commented Sep 6, 2014

There's something worth thinking about that bridging headers need to be user edited.

I see two reasonable ways to handle it:

  • The first time CocoaPods can check for a header with the same name as the lib, and if that exists add that to the bridging header but from then on basically doesn't edit it
  • Have a /// CocoaPods Generated Headers section that CocoaPods edits below giving the user the chance to make changes without being overwritten on the next pod install.

@CocoaPods CocoaPods unlocked this conversation Sep 6, 2014

@kylef

This comment has been minimized.

Copy link
Contributor Author

commented Sep 7, 2014

@orta @segiddins The bridging header should be the frameworks header which should exist most of the time, most frameworks/pods expose a single header to import. If there isn't one, we could generate one importing ever public header as @orta suggested. Example: https://github.com/QueryKit/QueryKit/blob/master/QueryKit/QueryKit.h

@segiddins

This comment has been minimized.

Copy link
Member

commented Sep 16, 2014

@kylef this already needs another rebase

@kylef kylef closed this Sep 17, 2014

@kylef

This comment has been minimized.

Copy link
Contributor Author

commented Sep 17, 2014

I think this is superseded by @mrackwitz, but I have pushed this change incase it is needed to be cherry-picked elsewhere or merged

@kylef kylef reopened this Sep 17, 2014

@kylef kylef force-pushed the swift branch from e09b7e0 to 27d1bd3 Sep 17, 2014

@misterfifths misterfifths referenced this pull request Sep 20, 2014
@acmacalister acmacalister referenced this pull request Sep 30, 2014

@kylef kylef closed this Oct 9, 2014

@kylef kylef deleted the swift branch Oct 9, 2014

@flovilmart

This comment has been minimized.

Copy link

commented Oct 20, 2014

@orta @segiddins Bridging headers are not supported in embedded frameworks, so that cuts the problem right away. Why not generate both Targets: Embedded Frameworks dynamically linkable (for usage in iOS8+) and static libs for the rest. Starting iOS 8, one should not rely on static linking as the recommended pattern involves dylibs for shared code between appExtensions and main app. Statically linked, that will produce ugly duplicates!

That should make the development easier, and also can be based on the platform flag of the podfile no?
And yes you can mix swift and ObjC in EF without the bridging header but that's messy all the way. Pods should be cocoa or swift, not mixed don't you think?

@mrackwitz mrackwitz referenced this pull request Nov 16, 2014
13 of 15 tasks complete
@alexeyxo alexeyxo referenced this pull request Dec 25, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.