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

AppAuth cannot be integrated as static libraries with CocoaPods because it does not define a module (DEFINES_MODULE) #844

Closed
jmagman opened this issue Mar 29, 2024 · 3 comments · Fixed by #845
Labels

Comments

@jmagman
Copy link

jmagman commented Mar 29, 2024

Describe the bug
AppAuth cannot be added as a transitive dependency of a CocoaPods pod, when built as a static library.

To Reproduce

  1. Install CocoaPods.
  2. In Xcode, make new iOS app project.
  3. cd into the directory and pod init to initialize CocoaPods.
  4. In the generated Podfile comment out use_frameworks! to embed as static libs. Add a pod that depends on AppAuth, for example, GTMAppAuth:
  # Comment the next line if you don't want to use dynamic frameworks
  # use_frameworks!
  pod 'GTMAppAuth', '4.1.1'
  1. Run pod install, which fails:
$ pod install
Analyzing dependencies
Downloading dependencies
Installing AppAuth (1.7.3)
Installing GTMAppAuth (4.1.1)
Installing GTMSessionFetcher (3.3.2)
[!] The following Swift pods cannot yet be integrated as static libraries:

The Swift pod `GTMAppAuth` depends upon `GTMSessionFetcher` and `AppAuth`, 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.

Expected behavior
pod install should succeed when adding a pod with a dependency on AppAuth.

Environment
macOS 14.4.1
CocoaPods 1.14.3

Additional context
AppAuth is not setting up a module, and doesn't have DEFINES_MODULE for that to be done automatically.

This can be fixed by adding DEFINES_MODULE to AppAuth.podspec. See CocoaPods documentation about modular headers.

  s.xcconfig = {
     'DEFINES_MODULE' => 'YES',
  }
@mdmathias
Copy link
Collaborator

Related issue: #559

@jmagman
Copy link
Author

jmagman commented Mar 29, 2024

Related issue: #559

Ah, yes this issue is a duplicate of that, I missed it. Fortunately you likely don't need to tackle creating a manual modulemap, adding that DEFINES_MODULE build setting to the xcconfig in the podspec should be enough. See also flutter/flutter#41007 and linked PRs for additional details about this problem.

@jmagman
Copy link
Author

jmagman commented Mar 29, 2024

GoogleSignIn just released 7.1.1, which updated the dependency
'GTMAppAuth', '>= 1.3', '< 3.0' to 'GTMAppAuth', '>= 4.1.1', '< 5.0'. That bumped GTMAppAuth from 2.0.0 (on my machine, but presumably on CI as well) to 4.1.1. And between those versions, GTMAppAuth migrated from Objective-C to Swift google/GTMAppAuth@2.0.0...4.1.1.

So it might be freshly complaining with that particular set of dependencies because the newly swift-ified Swift pod wants the Objective-C pod to define modules.

@mdmathias mdmathias removed the triage Issues that need to be triaged label Apr 1, 2024
auto-submit bot pushed a commit to flutter/packages that referenced this issue Apr 17, 2024
1. Update GoogleSignIn iOS SDK dependency to [7.1](https://github.com/google/GoogleSignIn-iOS/releases/tag/7.1.0), which supports privacy manifests.
1. Update "fetch deps step" to run `pod repo update` every time to avoid missing spec failure. Also added a fetch deps step to the all_packages builds, since those could also use a `pod repo update` but I didn't want to add more logic to those bash scripts.
```
     [!] CocoaPods could not find compatible versions for pod "GoogleSignIn":
       In Podfile:
         google_sign_in_ios (from `Flutter/ephemeral/.symlinks/plugins/google_sign_in_ios/darwin`) was resolved to 0.0.1, which depends on
           GoogleSignIn (~> 7.1)
     None of your spec sources contain a spec satisfying the dependency: `GoogleSignIn (~> 7.1)`.
```
https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8752192509749702705/+/u/Run_package_tests/download_Dart_and_iOS_deps/stdout

3. Looks like the new versions of [`GTMSessionFetcher`](https://github.com/CocoaPods/Specs/blob/master/Specs/c/e/3/GTMSessionFetcher/3.3.2/GTMSessionFetcher.podspec.json) and [`AppAuth`](https://github.com/CocoaPods/Specs/blob/master/Specs/b/b/9/AppAuth/1.7.3/AppAuth.podspec.json) don't define modules, so there's an error building it statically:
```
     [!] The following Swift pods cannot yet be integrated as static libraries:
     The Swift pod `GTMAppAuth` depends upon `GTMSessionFetcher` and `AppAuth`, 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.
```
I filed google/gtm-session-fetcher#384 and openid/AppAuth-iOS#844.

In the meantime, I updated the example apps to `use_frameworks!`, which would be on for Flutter Swift apps, but not Objective-C ones.  We could add something to the tool to detect this case, and suggest `use_frameworks!` be added?  

4.  Even though google_sign_in_ios does not contain Swift files, for some reason, there is a "pod lib lint" warning complaining `swift_version` isn't set. This seems related to `GTMAppAuth` dependency constraint that went from an Objective-C-only to Swift pod.  So I set `swift_version` since it's harmless.

```
- WARN  | swift: The validator used Swift `4.0` by default because no Swift version was specified. To specify a Swift version during validation, add the `swift_versions` attribute in your podspec. Note that usage of a `.swift-version` file is now deprecated.
```
https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8752100979634945505/+/u/Run_package_tests/validate_iOS_and_macOS_podspecs/stdout

## Issues

* Fixes flutter/flutter#145777
* Fixes flutter/flutter#145866
* See also flutter/flutter#137140
TecHaxter pushed a commit to TecHaxter/flutter_packages that referenced this issue May 22, 2024
1. Update GoogleSignIn iOS SDK dependency to [7.1](https://github.com/google/GoogleSignIn-iOS/releases/tag/7.1.0), which supports privacy manifests.
1. Update "fetch deps step" to run `pod repo update` every time to avoid missing spec failure. Also added a fetch deps step to the all_packages builds, since those could also use a `pod repo update` but I didn't want to add more logic to those bash scripts.
```
     [!] CocoaPods could not find compatible versions for pod "GoogleSignIn":
       In Podfile:
         google_sign_in_ios (from `Flutter/ephemeral/.symlinks/plugins/google_sign_in_ios/darwin`) was resolved to 0.0.1, which depends on
           GoogleSignIn (~> 7.1)
     None of your spec sources contain a spec satisfying the dependency: `GoogleSignIn (~> 7.1)`.
```
https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8752192509749702705/+/u/Run_package_tests/download_Dart_and_iOS_deps/stdout

3. Looks like the new versions of [`GTMSessionFetcher`](https://github.com/CocoaPods/Specs/blob/master/Specs/c/e/3/GTMSessionFetcher/3.3.2/GTMSessionFetcher.podspec.json) and [`AppAuth`](https://github.com/CocoaPods/Specs/blob/master/Specs/b/b/9/AppAuth/1.7.3/AppAuth.podspec.json) don't define modules, so there's an error building it statically:
```
     [!] The following Swift pods cannot yet be integrated as static libraries:
     The Swift pod `GTMAppAuth` depends upon `GTMSessionFetcher` and `AppAuth`, 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.
```
I filed google/gtm-session-fetcher#384 and openid/AppAuth-iOS#844.

In the meantime, I updated the example apps to `use_frameworks!`, which would be on for Flutter Swift apps, but not Objective-C ones.  We could add something to the tool to detect this case, and suggest `use_frameworks!` be added?  

4.  Even though google_sign_in_ios does not contain Swift files, for some reason, there is a "pod lib lint" warning complaining `swift_version` isn't set. This seems related to `GTMAppAuth` dependency constraint that went from an Objective-C-only to Swift pod.  So I set `swift_version` since it's harmless.

```
- WARN  | swift: The validator used Swift `4.0` by default because no Swift version was specified. To specify a Swift version during validation, add the `swift_versions` attribute in your podspec. Note that usage of a `.swift-version` file is now deprecated.
```
https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8752100979634945505/+/u/Run_package_tests/validate_iOS_and_macOS_podspecs/stdout

## Issues

* Fixes flutter/flutter#145777
* Fixes flutter/flutter#145866
* See also flutter/flutter#137140
arc-yong pushed a commit to Arctuition/packages-arc that referenced this issue Jun 14, 2024
1. Update GoogleSignIn iOS SDK dependency to [7.1](https://github.com/google/GoogleSignIn-iOS/releases/tag/7.1.0), which supports privacy manifests.
1. Update "fetch deps step" to run `pod repo update` every time to avoid missing spec failure. Also added a fetch deps step to the all_packages builds, since those could also use a `pod repo update` but I didn't want to add more logic to those bash scripts.
```
     [!] CocoaPods could not find compatible versions for pod "GoogleSignIn":
       In Podfile:
         google_sign_in_ios (from `Flutter/ephemeral/.symlinks/plugins/google_sign_in_ios/darwin`) was resolved to 0.0.1, which depends on
           GoogleSignIn (~> 7.1)
     None of your spec sources contain a spec satisfying the dependency: `GoogleSignIn (~> 7.1)`.
```
https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8752192509749702705/+/u/Run_package_tests/download_Dart_and_iOS_deps/stdout

3. Looks like the new versions of [`GTMSessionFetcher`](https://github.com/CocoaPods/Specs/blob/master/Specs/c/e/3/GTMSessionFetcher/3.3.2/GTMSessionFetcher.podspec.json) and [`AppAuth`](https://github.com/CocoaPods/Specs/blob/master/Specs/b/b/9/AppAuth/1.7.3/AppAuth.podspec.json) don't define modules, so there's an error building it statically:
```
     [!] The following Swift pods cannot yet be integrated as static libraries:
     The Swift pod `GTMAppAuth` depends upon `GTMSessionFetcher` and `AppAuth`, 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.
```
I filed google/gtm-session-fetcher#384 and openid/AppAuth-iOS#844.

In the meantime, I updated the example apps to `use_frameworks!`, which would be on for Flutter Swift apps, but not Objective-C ones.  We could add something to the tool to detect this case, and suggest `use_frameworks!` be added?  

4.  Even though google_sign_in_ios does not contain Swift files, for some reason, there is a "pod lib lint" warning complaining `swift_version` isn't set. This seems related to `GTMAppAuth` dependency constraint that went from an Objective-C-only to Swift pod.  So I set `swift_version` since it's harmless.

```
- WARN  | swift: The validator used Swift `4.0` by default because no Swift version was specified. To specify a Swift version during validation, add the `swift_versions` attribute in your podspec. Note that usage of a `.swift-version` file is now deprecated.
```
https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8752100979634945505/+/u/Run_package_tests/validate_iOS_and_macOS_podspecs/stdout

## Issues

* Fixes flutter/flutter#145777
* Fixes flutter/flutter#145866
* See also flutter/flutter#137140
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants