search

grpc / grpc-swift

The Swift language implementation of gRPC.
Apache License 2.0
2.03k stars 420 forks source link

Using modular headers with SwiftNIO CocoaPods #960

Open Noveen opened 4 years ago

Noveen commented 4 years ago

I am trying to implement grpc-swift in my project.

I have created a demo app and it's working fine.

But when I try to replicate the same in my project I face the issues related to static dependency

The following Swift pods cannot yet be integrated as static libraries:

The Swift pod SwiftNIO depends upon CNIOLinux, CNIODarwin, CNIOAtomics, and CNIOSHA1, which do not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set use_modular_headers! globally in your Podfile, or specify :modular_headers => true for particular dependencies.

and also few more.

The problem is :modular_headers => true is not working for a particular dependencies,

and also I can't use_modular_headers! globally since it affects other pods,

I cannot use 'use_framework!' as this is also affects others.

The workaround I did is as follows

pod 'CNIOLinux', '= 2.20.2',:modular_headers => true pod 'CNIODarwin', '= 2.20.2',:modular_headers => true pod 'CNIOAtomics', '= 2.20.2',:modular_headers => true pod 'CNIOSHA1', '= 2.20.2',:modular_headers => true pod 'CNIOHTTPParser', '= 2.20.2',:modular_headers => true pod 'CNIOBoringSSL',:modular_headers => true pod 'CNIOBoringSSLShims',:modular_headers => true

Which is working.

But I don't want to follow this.

Lukasa commented 4 years ago

Unless we can work around this with the grpc podfile directly I think this is the only workable outcome. The above-mentioned dependencies have no module map on purposes: Swift Package Manager uses this as a signal to follow a specific code path through the code that gives us better Xcode interoperability when using the old-school swift package generate-xcodeproj style package generation. We are unwilling to give that up, so we need a way to get cocoa pods to do what we need.

Lukasa commented 4 years ago

@MrMage Are you happy to drive updating our pod files to reflect this need?

MrMage commented 4 years ago

Would this be about simply adding , :modular_headers => true to all the dependency lines in the gRPC Podspec? If so, what would be the negative/positive side-effects of that? And should it really be the default, or be kept optional for those who really need it, as is currently the case?

As an alternative, it might be possible to provide a module map for the NIO modules that is used only by CocoaPods but not SwiftPM.