Plugin target deployments are out of range, causes Xcode warning #40109

Activity

1. jmagman

   added

   toolAffects the "flutter" command-line tool. See also t: labels.Affects the "flutter" command-line tool. See also t: labels.

   plugin

   t: xcode"xcodebuild" on iOS and general Xcode project management"xcodebuild" on iOS and general Xcode project management

   on Sep 9, 2019
2. jmagman commented on Sep 9, 2019

   

   jmagman

   on Sep 9, 2019

   MemberAuthor

   More actions

   Proposal from #36117 (comment):

   After reading CocoaPods/CocoaPods#7314 I don't really want to imply libraries support a higher version than they claim to, or worse claim they support a higher version, but I also really hate warnings in dependencies you have no power to fix.

   At a minimum, the the 8.0 version in the change doesn't match the version at the top.

   # Uncomment this line to define a global platform for your project
   # platform :ios, '9.0'
   

   And now we're chasing a moving target of whatever Xcode decides is the minimum deploy version.
   What if we did this:

   config.build_settings.delete 'IPHONEOS_DEPLOYMENT_TARGET'
   

   Then the individual pod targets will inherit IPHONEOS_DEPLOYMENT_TARGET either from the Pods project from that platform :ios call, or inherit from the SDK platform?

   Whatever we do in this Podfile should be duplicated in Podfile-ios-swift and Podfile-macos.

   First attempt:
   #36117 (comment)

   I started with:

   post_install do |installer|
   ...
   {{^withPluginHook}}
         # Inherit the deployment target from the `platform :ios` call above to avoid un-fixable warnings.
         config.build_settings.delete 'IPHONEOS_DEPLOYMENT_TARGET'
   {{/withPluginHook}}
   

   but it doubles down on the Podfile being a template, which goes against @xster's request for it to become dynamically generated here #9827

   I need to find a mechanism to know if the app is a plugin example app AFTER the project is already generated, which there isn't right now AFAIK.

   And eventual roadblock:
   #36117 (comment)

   Oh yeah, and the other issue is that the Podfile isn't added on create, it's actually added when the first plugin is added. So at that point withPluginHook isn't available, either.
3. jmagman commented on Jan 24, 2020

   

   jmagman

   on Jan 24, 2020

   MemberAuthor

   More actions

   I changed my mind, ignoring the plugin minimum version is probably a bad idea. Closing.
4. jmagman

   closed this as completedon Jan 24, 2020
5. jmagman

   reopened this on Sep 18, 2020
6. jmagman commented on Sep 18, 2020

   

   jmagman

   on Sep 18, 2020

   MemberAuthor

   More actions

   New thought: as of #59044 we have a lot more control over this logic, and changes don't require a developer Podfile migration.

   We can parse the minimum versions post-install, and only config.build_settings.delete 'IPHONEOS_DEPLOYMENT_TARGET' if the minimum version is less than the project's version.
   

   flutter/packages/flutter_tools/bin/podhelper.rb

   Line 29 in 3744b82

   def flutter_additional_ios_build_settings(target)

   See https://www.rubydoc.info/github/CocoaPods/Core/Pod/Podfile
7. jmagman

   closed this as completedin #66590on Sep 28, 2020
8. github-actions commented on Aug 12, 2021

   

   github-actionsbot

   on Aug 12, 2021

   More actions

   This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
9. github-actions

   locked as resolved and limited conversation to collaborators on Aug 12, 2021
10. flutter-triage-bot

    added

    packageflutter/packages repository. See also p: labels.flutter/packages repository. See also p: labels.

    on Jul 5, 2023