Creazione di una libreria statica con cocoapod

Question

Sto provando a creare una libreria statica con dipendenze diverse (ad esempio, AFNetworking) specificata in un Podfile. Non voglio che le dipendenze siano incluse nella libreria statica finale (richiama libMyProject.a), voglio solo collegarmi a loro e quindi creare un file MyProject.Podspec dove posso mettere le stesse dipendenze.

Il problema è che quando costruire il libMyProject.a libPods.a è legata e comprendeva, in modo che se distribuisco libMyProject.a e le altre persone lo integra in un progetto che usa alcune delle stesse dipendenze che avrà duplicato problemi di simboli.

Come posso collegarmi alla lib libodods.a ma non includerlo in libMyProject.a? Dovrebbe funzionare proprio come il collegamento con altri framework esistenti.

Grazie!

Answer 1

L'ho risolto rimuovendo lib libods.a dalla sezione "Collega binari con librerie" in Fasi di costruzione.

Answer 2

Mentre la rimozione manuale di libPods.a dalla fase di compilazione "Collega binari con librerie" funziona davvero, la vera risposta è non lasciare che venga aggiunta lì in primo luogo.

Il motivo per cui viene aggiunto è perché il comando di installazione del pod sta trovando il target della libreria statica come uno dei suoi target a cui collegarsi. Ciò potrebbe essere dovuto al fatto che è il primo obiettivo nell'elenco (l'implementazione dei cocoapodi gli consente di scegliere il primo se non hai specificato esplicitamente gli obiettivi) o potrebbe esserlo perché lo hai esplicitamente dichiarato nella sezione "link_with".

La risposta che trovo è utilizzare la sezione link_with del Podfile per indicare esplicitamente le destinazioni e omettere la destinazione della libreria statica.

Il progetto dei pod viene comunque creato e le dipendenze vengono portate lì come ci si aspetterebbe, ma libPods.a non viene aggiunto alla fase di creazione della libreria statica.

L'unico problema è cosa inserire nella sezione link_with, se non nella libreria statica. Se hai altri obiettivi con i quali vuoi collegarti (ad esempio un obiettivo per iPhone, questa è una buona scelta. Ma se il tuo unico vero obiettivo è la tua libreria statica, hai bisogno di un po 'di soluzione.

La mia strategia di successo finora è stata quella di creare un target di libreria statico (sì, uno separato dalla libreria statica principale statica) e chiamarlo "Dummy". Specifica questo target nella sezione link_with del tuo Podfile.

È un po 'spiacevole, scontato, ma funziona.

platform :ios, '5.1.1' 

link_with ['Dummy'] 

pod 'AFNetworking', '= 1.3.1' 

Answer 3

Le librerie di riferimento non sono incluse (di default) nel prodotto della libreria statica. Il conflitto del linker che stai vedendo è più probabilmente il risultato sia della tua libreria statica che dell'app client utilizzando sia l'obiettivo Pod (implicito) predefinito.

Ogni obiettivo generato da Cocoapods include un file "Pods- target -dummy.m" compilato nel prodotto; se usi il target di pod predefinito, viene chiamato semplicemente "Pods-dummy.m". Quando sia la libreria che il client utilizzano la destinazione predefinita, i simboli identici prodotti dalla compilazione dei file fittizi causeranno un errore di collegamento.

Ho provato personalmente una variazione di Craig's answer e ho riscontrato che l'istruzione è anche responsabile dell'aggancio dell'xcconfig generato da Cocoapods, che fornisce i flag del compilatore che controllano il percorso di ricerca dell'intestazione. È possibile aggiungere manualmente xcconfig (o le impostazioni del progetto del percorso di ricerca dell'intestazione), ma sono andato alla ricerca di una soluzione ripetibile per il mio team.

La mia soluzione è quella di creare un obiettivo esplicito per la biblioteca, con un nome che è improbabile da causare conflitti con un progetto client (ad esempio, il nome della libreria):

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

è possibile includere un'istruzione link_with all'interno del blocco target se il nome della destinazione della libreria statica (nel progetto Xcode) è diverso, ma se è presente un solo obiettivo, di solito preferisco utilizzare lo stesso nome in entrambe le posizioni, rendendo inutile link_with.

Se si dispone di un target di test unitario, creare due target separati. (. Io attualmente def una serie di pod comuni che vengono utilizzati in entrambi gli obiettivi, dal momento che gli obiettivi astratti non sono attualmente un'opzione, ma possono essere un giorno) Ecco come si presenta:

def common_pods 
    pod 'AFNetworking', '2.5.2' 
end 

target 'XYZLibrary' do 
    common_pods 
end 

target 'XYZLibraryTests' do 
    common_pods 
end 

La chiave è quella di non avere elementi pod nella radice del Podfile, in modo che Cocoapods non generi una destinazione predefinita. In questo modo, ogni prodotto riceve un esclusivo "Baccello- target -dummy.m" e non c'è conflitto quando questi file oggetto sono collegati insieme.