Aufbau einer statischen Bibliothek mit cocoapods

Ich versuche zu bauen, eine statische Bibliothek, die verschiedene Abhängigkeiten (AFNetworking zum Beispiel) angegeben Podfile. Ich will nicht die Abhängigkeiten enthalten sein, in der statischen Bibliothek (Aufruf libMyProject.a) ich möchte nur Links vor Ihnen, und erstellen Sie dann ein MyProject.Podspec Datei, wo ich die gleichen Abhängigkeiten.

Das problem ist, dass wenn ich bauen libMyProject.eine der libPods.a verknüpft ist und im Lieferumfang enthalten, so dass, wenn ich verteilen libMyProject.einen anderen Menschen und integriert Sie in einem Projekt verwendet einige der gleichen Abhängigkeiten wird es doppelte Symbole Probleme.

Wie kann ich den link gegen die libPods.eine lib, aber es nicht in libMyProject.ein? Es sollte funktionieren, genauso wie Vernetzung mit anderen, bereits bestehenden frameworks.

Dank!

  • Wenn die Antwort, die Sie Hinzugefügt unterhalb korrekt ist, markieren Sie Sie als solche, so dass diese Frage nicht mehr zeigt, als zu öffnen.
InformationsquelleAutor javierdfm | 2013-06-13
  1. 12

    Ich löste es durch das entfernen der libPods.eine lib aus dem Abschnitt "Link-Binary Mit Bibliotheken" in den Build-Phasen.

    • Ich glaube, dass diese Antwort richtig ist und ich näher auf meine Lösung zu diesem hier: stackoverflow.com/a/17869668/106703
    • Gibt es eine intelligente Möglichkeit zur Automatisierung dieser Entfernung? Ich habe versucht mehrere Ansätze, jedoch ohne Erfolg.
    • siehe meine Antwort für die automatisierte removal (oder genauer, wie Sie vermeiden, indem es in den ersten Platz).
    InformationsquelleAutor javierdfm
  2. 6

    Während das manuelle entfernen der libPods.eine von der "Link-Binary mit Bibliotheken" build-phase funktioniert in der Tat, die wirkliche Antwort ist, um nicht lassen Sie es Hinzugefügt werden, gibt es in den ersten Platz.

    Der Grund, dass es Hinzugefügt ist, weil der pod install-Befehl zu finden, ist die statische Bibliothek Ziel als eines seiner Ziele, um die Verknüpfung mit. Das könnte sein, denn es ist das erste Ziel in der Liste (cocoapods Umsetzung bewirkt, dass es einfach das erste, wenn Sie nicht explizit angegeben Ziele) oder es könnte sein, denn Sie haben ausdrücklich erklärt, dass es in der 'link_with' Abschnitt.

    Die Antwort, die ich finde, ist die Verwendung der link_with Abschnitt der Podfile, um explizit Ihre Ziele, und weglassen der statischen Bibliothek Ziel.

    Dem pods-Projekt wird noch erstellt, und Ihre Abhängigkeiten gebracht, wie Sie es erwarten würden, aber die libPods.ein nicht Hinzugefügt, um die build-phase des statischen Bibliothek.

    Das problem ist nur, was in der link_with Abschnitt, wenn nicht die statische Bibliothek. Wenn Sie haben andere Ziele, Sie wollen, um die Verknüpfung mit (eine iPhone app target zum Beispiel) das ist eine gute Wahl. Aber wenn Ihre einzige wirkliche Ziel ist die statische Bibliothek, die Sie benötigen, ein wenig Abhilfe.

    Meine erfolgreiche Strategie war bisher zum erstellen einer statischen Bibliothek Ziel (ja, eine einzelne von Ihr main statische Bibliothek) und nennen es "Dummy". Geben Sie dieses Ziel in Ihrem Podfile ist link_with Abschnitt.

    Ist es ein wenig geschmacklos, zugegeben, aber es funktioniert.

    platform :ios, '5.1.1'

link_with ['Dummy']

pod 'AFNetworking', '= 1.3.1'
    • Dies funktioniert gut, aber Sie müssen möglicherweise auch um die Konfiguration, die Sie statische Bibliothek Ziel Pods.xcconfig, ansonsten ist der Header der abhängigen Bibliotheken können nicht verwendet werden, die in Ihrer statischen Bibliothek.
    • Können Sie uns ein Beispiel Podfile? Dies funktioniert nicht für mich.
    • Ich aktualisiert die post, um eine vollere Beispiel einer podfile.
    • Dies funktioniert nicht für mich 🙁
    • Möglicherweise müssen Sie manuell hinzufügen, die Cocoapods-generiert xcconfig (z.B. Hülsen.debug.xcconfig), um Ihre Xcode-Projekt Konfiguration (Projekt - > Info > - Konfigurationen) für die header-Suche zu arbeiten. Ich habe dieses Muster zu arbeiten, aber ich kam mit der eine weitere Lösung.
    InformationsquelleAutor Craig Russell
  3. 1

    Referenzierten Bibliotheken nicht (standardmäßig) enthalten sind, in die statische Bibliothek Produkt. Die linker-Konflikt, die Sie sehen, ist eher das Ergebnis von sowohl Ihre statische Bibliothek und der client-app sowohl mit dem Standard - (implizite) - Pod Ziel.

    Jeder Cocoapods-generated target enthält eine "Hülsen-Ziel-dummy.m" - Datei, die kompiliert wird in das Produkt, wenn Sie den Standard-Pods Ziel, es ist nur als "Hülsen-dummy.m". Wenn sowohl die Bibliothek als auch client verwenden Sie die Standard-Ziel, die identische Symbole produziert kompilieren Sie die dummy-Dateien verursachen ein link-Fehler.

    Habe ich versucht, eine variation von Craigs Antwort mich, und festgestellt, dass die link_with Aussage ist auch verantwortlich für den Anschluss der xcconfig generiert, die von Cocoapods, die die compiler-flags, die Steuern, die header-Suchpfad. Sie können die xcconfig (oder der header-Suchpfad Projekt-Einstellungen) manuell, natürlich, aber ich ging auf der Suche für eine reproduzierbare Lösung für mein team.

    Meine Lösung zu schaffen, ist ein explizites Ziel für die Bibliothek, mit einem Namen, der wohl dazu führen, dass Konflikte mit einem client-Projekt (Z. B. den Namen der Bibliothek):

    target 'XYZLibrary' do
    pod 'AFNetworking', '2.5.2'
    ...
end

    Können Sie eine link_with - Anweisung innerhalb der target block, wenn der name der statischen Bibliothek Ziel (in Ihrem Xcode-Projekt) ist anders, aber wenn es nur noch ein Ziel, ich in der Regel lieber mit den gleichen Namen in beiden Orten, so dass link_with unnötig.

    Wenn Sie einen unit-test-target-erstellen Sie zwei separate Ziele. (Ich habe derzeit def ein gemeinsamer Satz von Hülsen, die verwendet werden, in der beide Ziele, da abstrakte Ziele sind derzeit nicht eine option, aber Sie werden vielleicht eines Tages.) Es sieht wie folgt aus:

    def common_pods
  pod 'AFNetworking', '2.5.2'
end

target 'XYZLibrary' do
  common_pods
end

target 'XYZLibraryTests' do
  common_pods
end

    Der Schlüssel ist, um keine pod Elemente in der Wurzel der Podfile, so dass Cocoapods nicht generiert ein default-target. So, jedes Produkt erhält eine eindeutige "Hülsen-Ziel-dummy.m", und es gibt keinen Konflikt, wenn diese object-Dateien sind miteinander verknüpft.

    InformationsquelleAutor big_m
Schreibe einen Kommentar