wake-up-neo.com

So verwenden Sie CocoaPods mit mehreren Framework-Teilprojekten

Zunächst einmal habe ich use_framework eingeschaltet! in podfile.

Angenommen, das Hauptprojekt ist MAIN_APP, und zwei Unterprojekte sind FRAMEWORK_A und FRAMEWORK_B.

MAIN_APP erfordert FRAMEWORK_A und FRAMEWORK_B, und FRAMEWORK_B erfordert auch FRAMEWORK_A.

Alle Projekte/Ziele verwenden CocoaPods zur Verwaltung von Bibliotheken von Drittanbietern.

Im Moment sieht meine Poddatei folgendermaßen aus:

target :MAIN_APP do
    project 'MAIN_APP'
    pod 'PodA'
end

target :FRAMEWORK_A do
    project 'FRAMEWORK_A'
    pod 'PodB'
end

target :FRAMEWORK_B do
    project 'FRAMEWORK_B'
    pod 'PodC'
end

Ich habe manuell FRAMEWORK_A hinzugefügt, um Einstellungen von FRAMEWORK_B zu erstellen, und sowohl FRAMEWORK_A als auch FRAMEWORK_B, um Einstellungen von MAIN_APP zu erstellen.

Der gesamte Code lässt sich gut kompilieren, stürzt jedoch ab, wenn MAIN_APP ausgeführt wird, da Framework von PodB nicht geladen werden kann.

Ich weiß, dass ich PodB auch manuell zu MAIN_APP und FRAMEWORK_B hinzufügen kann, aber ist es möglich, diese Art von Zielabhängigkeit in Podfile zu definieren?

Übrigens, als pod install bekam ich die Warnung:

[!] Die Poddatei enthält Framework-Ziele, für die die Poddatei keine Host-Ziele enthält (Ziele, die das Framework einbetten).

Wenn dieses Projekt für die Framework-Entwicklung vorgesehen ist, können Sie diese Nachricht ignorieren. Fügen Sie der Pod-Datei ansonsten ein Ziel hinzu, das diese Frameworks einbettet, damit diese Nachricht nicht mehr angezeigt wird (z. B. ein Testziel).

Wie ich weiß, kann ich verschachtelte Ziele für Host-Ziele verwenden, wie:

target :FRAMEWORK_A
    target :MAIN_APP
    end
end

Daher richtet CocoaPods MAIN_APP für die Verwendung von FRAMEWORK_A ein und erbt Pod-Abhängigkeiten von FRAMEWORK_A. Aber ich schaffe es nicht mit mehreren Abhängigkeiten wie:

target :FRAMEWORK_A
    target :MAIN_APP
    end
end
target :FRAMEWORK_B
    target :MAIN_APP
    end
end

Weil target: MAIN_APP kann nicht zweimal deklariert werden.

Gibt es bessere Lösungen, anstatt Pod-Abhängigkeiten als Funktion in Podfile zu definieren und in all target einzubeziehen?

22
Allen Hsu

Dies ist eine großartige Frage, und ich habe mit einer ähnlichen Situation zu kämpfen. Das ist mein PodFile:

platform :ios, '8.0'

workspace 'mygreatapp.xcworkspace'

project 'app/MyGreatApp/MyGreatApp.xcodeproj'
project 'platform/MyGreatFramework/MyGreatFramework.xcodeproj'

abstract_target 'This can say whatever you want' do

    target 'MyGreatApp' do
        project 'app/MyGreatApp/MyGreatApp.xcodeproj'
        pod 'AFNetworking', '~> 2.6.0'
        pod 'PromiseKit', '~> 1.5'
        pod 'PromiseKit/Join'
        pod 'KVOController', '~> 1.0'
        pod 'FLAnimatedImage', '~> 1.0'
        pod 'Crashlytics', '~> 3.3'
        pod 'SSZipArchive'
    end

    target 'MyGreatAppTests' do
        project 'app/MyGreatApp/MyGreatApp.xcodeproj'
        pod 'OCMock', '~> 3.1'
    end

    target 'MyGreatFramework' do
        project 'platform/MyGreatFramework/MyGreatFramework.xcodeproj'
        pod 'SSZipArchive'
    end

    target 'MyGreatFrameworkTests' do
        project 'platform/MyGreatFramework/MyGreatFramework.xcodeproj'
        pod 'OCMock', '~> 3.1'
    end

    post_install do |installer|
      installer.pods_project.targets.each do |target|
        target.build_configurations.each do |config|
          config.build_settings['ENABLE_BITCODE'] = 'NO'
        end
      end
    end
end

Wie Sie sehen, verwende ich keine Frameworks und verwende einen abstract_target, um alles zu gruppieren. Ich wünschte, diese Abhängigkeiten wären in CocoaPods einfacher zu bewerkstelligen. Ich weiß, dass dies Ihre Frage nicht wirklich beantwortet, aber es könnte trotzdem hilfreich sein.

2

Ich denke, Sie können dies auch umgehen, indem Sie einfach FrameworkA und FrameworkB in lokale Pods (statische Bibliothek) umwandeln. Dadurch wird alles für Sie de-dupliziert und in die Host-App integriert. 

Beispiele: https://github.com/rob-keepsafe/PodFrameworksIssue

  • master branch zeigt doppelte Klassen und übergeordnete Frameworks wie Sie
  • deduped branch macht die internen dynamischen Frameworks in lokale Pods (als statische Bibliotheken), um die Abhängigkeiten zu dupe- len und dennoch zu verknüpfen
0
iwasrobbed