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
Swift Static Library support #6966
Conversation
This is fantastic! I'm testing it out now, the first big issue I've noticed is that Swift pods with Swift dependencies need their dependencies' build paths in their |
Here's a sample project for this TestSwiftNestedDependencies.zip (looks like Sonar doesn't actually compile in Swift 4, but it still shows the issue). This can be fixed by adding |
The next issue I've noticed is that if you have a Swift pod that depends on an Objective-C pod, it has trouble building the module: Here's an example project TestObjectiveCDependency.zip In this project I've added the |
@keith Both of those projects build for me now 👍. |
Nice! Looks like that works on my end too. I noticed that specs using |
73227d6
to
c20ac94
Compare
@keith I wasn't sure if it was going to be needed, but looks like it will be 👍 |
Next thing I ran into is it seems that the Facebook SDK fails to build statically because of some non modular include warnings. I don't see this when using frameworks today. This obviously could 100% be on them, but figured it was worth mentioning. Here's a sample project: TestFacebookSDK.zip |
Hmm actually it looks like it's happening with other Objective-C pods we're using as well. I can give another project example if needed. |
@keith Good to know - a smaller example than FBSDK would be handy, but I think that's because I'm not preserving header paths properly yet. |
Here's a slightly smaller example. It appears to be an issue with imports referencing nested Objective-C dependencies, so this example also has 2 dependencies: TestLightstep.zip |
Ah the problem appears to be the imports in the umbrella header generated by CP. In both of these sample projects, commenting all the imports in that file out makes them compile. |
Is there a |
@dantoml I tried your branch and applied it to our large scale project. In addition to your changes, I also made following changes for our project to build:
There is however one issue left: make a swift class visible to ObjC class which depends on the lib. In theory this requires @import module -> modulemap -> umbrella -> module-Swift.h inclusion chain. I can copy it from derived-object folder but I am not sure if it's the best approach. I attached my diff. It's just a quick hack and really messy. Let me know if you wanna collaborate. |
Is this branch still being updated? Is there anything we can do to help move this along? |
@Pearapps yes! if you feel you can move this faster than the current pace feel free to pick it up and get it past the finish line. As a reminder, most of the work in CocoaPods is done from people's free time. There is never a deadline or strict timeline to get things done. |
I opened up a PR against this that uses that diff that @chenxiao0228 put up in a previous comment #7067 |
Sorry for the silence on this, I've been super busy lately, and CocoaPods feature work has taken a back seat. I'm taking another look at this today. |
@chenxiao0228 Thanks for that diff, coercing module maps into the right format was one of the things I was wondering about. |
c20ac94
to
9d9e561
Compare
@@ -88,6 +88,9 @@ def custom_build_settings | |||
settings['PRIVATE_HEADERS_FOLDER_PATH'] = framework_name + '.framework' + '/PrivateHeaders' | |||
end | |||
else | |||
# if target.uses_swift? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
commented code
Punted to 1.5.0. |
Reviving this for 1.5.0 now that 1.4.0 shipped. |
9d9e561
to
3e826eb
Compare
xcodebuild fails if a framework target has PRODUCT_MODULE_NAME
While well-intentioned, they broke cross-project target dependency detection
… umbrella headers This allows us to avoid incomplete umbrella header warnings
By default, targets integrated as static libraries _will not_ get a module map, unless they opt-in by including `DEFINES_MODULE = YES` in their specification's `pod_target_xcconfig`
This is to mirror our use of -isystem for header search paths, making it so that headers imported via <> have warnings supressed
…ublic headers path
…ries and objective c modules
139de10
to
70b5bb9
Compare
Rebased, this is basically ready to go! |
70b5bb9
to
11c9226
Compare
Question: Will this resolve the issue with transitive dependency stuff? |
Closes #6899.