Costruire una libreria statica con cocoapods

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

Il problema è che quando costruisco libMyProject.a libPods.a è collegato e incluso, così che se distribuisco libMyProject.a e altre persone lo integri in un progetto che usa alcune delle stesse dependencies avrà problemi con simboli duplicati.

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

Grazie!

Solutions Collecting From Web of "Costruire una libreria statica con cocoapods"

L'ho risolto rimuovendo lib libods.a dalla sezione "Collega il file binario con le librerie" in Fasi di compilazione.

Mentre la rimozione manuale di libPods.a dalla fase di build "Link Binary with Libraries" funziona davvero, la vera risposta è di non farcela aggiungere lì in primo luogo.

Il motivo per cui viene aggiunto è perché il command di installazione del pod sta trovando il target della libreria statica come uno dei suoi target con cui collegarsi. Ciò potrebbe essere dovuto al fatto che è il primo objective 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 è di usare la sezione link_with del Pod per dichiarare esplicitamente i tuoi obiettivi e omettere il target della libreria statica .

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

L'unico problema è cosa mettere nella sezione link_with, se non nella tua libreria statica. Se hai altri obiettivi con i quali vuoi collegarti (ad esempio un objective per iPhone, questa è una buona scelta. Ma se il tuo unico vero objective è 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 ) 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' 

Le librerie di riferimento non sono (di default) incluse 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'objective Pod (implicito) predefinito.

Ogni objective generato da Cocoapods include un file "Pods- target -dummy.m" che viene compilato nel prodotto; se si utilizza 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 della risposta di Craig e link_with scoperto che l'istruzione link_with è anche responsabile dell'aghook dell'xcconfig generato da Cocoapods, che fornisce i flag del compilatore che controllano il path di ricerca dell'intestazione. È ansible aggiungere manualmente xcconfig (o le impostazioni del progetto del path di ricerca dell'intestazione), ma sono andato alla ricerca di una soluzione ripetibile per il mio team.

La mia soluzione è creare un target esplicito per la libreria, con un nome che non dovrebbe causare conflitti con un progetto client (ad esempio, il nome della libreria):

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

Puoi includere un'istruzione link_with nel block di target se il nome del target della libreria statica (nel tuo progetto Xcode) è diverso, ma se c'è un solo target, di solito preferisco usare lo stesso nome in entrambe le posizioni, rendendo inutile link_with .

Se hai un objective di test unitario, crea due bersagli separati. (Al momento non definisco un insieme di pod comuni utilizzati in entrambi i target, dal momento che gli obiettivi astratti non sono attualmente un'opzione, ma potrebbero essere un giorno.) Sembra che questo:

 def common_pods pod 'AFNetworking', '2.5.2' end target 'XYZLibrary' do common_pods end target 'XYZLibraryTests' do common_pods end 

La chiave è di non avere alcun elemento pod nella root del Podfile, in modo che Cocoapods non generi un target predefinito. In questo modo, each prodotto riceve un esclusivo "Pods- target -dummy.m" e non c'è conflitto quando questi file object sono collegati tra loro.