You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add "pod lib lint --use-libraries" to GitHub actions to validate GoogleSignIn builds as a library #33
# Tests are skipped since the Swift tests need modules.'--skip-tests --use-libraries'
"Tests are skipped since the Swift tests need modules" is the same bug in that repo as #32. I filed this GitHub Action request to validate the modules are generated for libraries when that issue is fixed, which can be done by adding an @import GoogleSignIn in the unit tests or making any of them Swift files.
That's arguably not a bug since it can be argued that the decision to use modules or not should be left to the pod consumer who can specify use_frameworks! or use_frameworks! :linkage => :static to generate frameworks and modules if desired. I believe CocoaPods has always documented that Swift clients should use use_frameworks! and it was changed awhile ago so that the Podfile created by pod init has use_frameworks! on. I realize that I'm treating modules and frameworks as a synonym, and maybe that's an issue, but we haven't heard about it from Firebase clients.
Indeed, Swift clients should use use_frameworks!. I investigated this more in flutter/flutter#25676 (comment) (mostly in the context of Swift plugins being consumed by Objective-C clients). However there's no reason not to support module maps regardless of the client language. DEFINES_MODULE=YES is the default build setting in a new vanilla Xcode Objective-C or Swift framework targets.
In any case for the sake of this GitHub Action request, --use-libraries is still a good thing to test for Objective-C clients.
Activity
paulb777 commentedon Jul 20, 2021
Here's an example that also tests
--use-static-frameworkas well as other Apple platforms - https://github.com/firebase/firebase-ios-sdk/blob/master/.github/workflows/core.yml#L68jmagman commentedon Jul 20, 2021
https://github.com/firebase/firebase-ios-sdk/blob/04ab074265633049d5518866515e3bd7fc0de246/.github/workflows/core.yml#L78-L79
says
"Tests are skipped since the Swift tests need modules" is the same bug in that repo as #32. I filed this GitHub Action request to validate the modules are generated for libraries when that issue is fixed, which can be done by adding an
@import GoogleSignInin the unit tests or making any of them Swift files.paulb777 commentedon Jul 20, 2021
That's arguably not a bug since it can be argued that the decision to use modules or not should be left to the pod consumer who can specify
use_frameworks!oruse_frameworks! :linkage => :staticto generate frameworks and modules if desired. I believe CocoaPods has always documented that Swift clients should useuse_frameworks!and it was changed awhile ago so that thePodfilecreated bypod inithasuse_frameworks!on. I realize that I'm treating modules and frameworks as a synonym, and maybe that's an issue, but we haven't heard about it from Firebase clients.jmagman commentedon Jul 20, 2021
Indeed, Swift clients should use
use_frameworks!. I investigated this more in flutter/flutter#25676 (comment) (mostly in the context of Swift plugins being consumed by Objective-C clients). However there's no reason not to support module maps regardless of the client language.DEFINES_MODULE=YESis the default build setting in a new vanilla Xcode Objective-C or Swift framework targets.In any case for the sake of this GitHub Action request,
--use-librariesis still a good thing to test for Objective-C clients.paulb777 commentedon Jul 20, 2021
Agreed, and also
--use-static-frameworktesting should be added since that is the more modern way to choose static linking.