Gestione delle dipendenze nelle librerie statiche con cocoapod

Question

Uso CocoaPods in un'app in cui l'area di lavoro è costituita da un progetto di applicazione principale e alcune librerie statiche come sottoprogetti, ciascuna con le proprie dipendenze. Le librerie statiche sono collegate al progetto principale in fase di compilazione e esistono principalmente come mezzo per incapsulare e organizzare il codice.

Un problema sorge dove CocoaPods collega le dipendenze alle librerie statiche dei sottoprogetti. Se due o più di queste librerie statiche hanno le stesse dipendenze, non possono essere entrambe collegate al progetto principale, in quanto ciò si traduce in simboli duplicati.

La soluzione temporanea che ho al momento è quella di creare una destinazione "fittizia" in ciascuno dei sottoprogetti e impostarla come destinazione del collegamento nel file pod. Il vero target utilizza il file xcconfig generato da CocoaPods, senza nessuna delle dipendenze collegate.

Mentre questo funziona davvero, e id è la soluzione più semplice che ho trovato, porta ancora il peso extra inutile di avere un manichino bersaglio in ogni progetto, ad esempio:

xcodeproj 'MyApp/MyApp.xcodeproj' 
target :'MyApp' do 
    xcodeproj 'MyApp/MyApp.xcodeproj' 

    pod 'MBProgressHUD',   '0.9' 

    link_with 'PodDummy' 
end 

Un altro svantaggio di questo approccio è che tutte le dipendenze devono ancora essere specificata nel progetto principale comunque, in modo che siano connessi con l'eseguibile finale.

---

Quindi la mia domanda è: come posso utilizzare CocoaPods in un progetto di libreria statica, senza dover collegare le dipendenze nel binario?

O meglio ancora: potrei specificare le dipendenze solo nei sottoprogetti della libreria statica e far sì che CocoaPods comprenda cosa deve essere collegato nel progetto principale, risolvendo i duplicati nel processo?

Sto pensando di includere solo il progetto principale nel file pod e fare in modo che i sottoprogetti facciano riferimento manualmente alla directory "Pod" per le intestazioni.

Sembra esserci stata qualche discussione sul problema in passato, ma non riesco a vedere cosa ne sia venuto fuori, se non altro. Relative discussioni sono:

1. https://github.com/CocoaPods/CocoaPods/issues/1335
2. https://github.com/CocoaPods/CocoaPods/issues/840
3. iOS Static Library + CocoaPods and the duplicate symbols error
4. Kiwi and CocoaPods with a static shared library

Answer 1

CocoaPods funziona bene per le persone che utilizzano cialde. È molto più difficile usarlo quando sviluppi i pod o, peggio, quando sviluppi un'app insieme a (a) librar (y) ie che sono tutti i pod ... (che possono dipendere anche dai pod).

Quello che devi sapere è che CocoaPods è qui per risolvere le dipendenze. Il tuo problema mi sembra che tu abbia completamente aggirato questa caratteristica avendo i tuoi pod in dev già nel tuo spazio di lavoro! Naturalmente, se esegui una "installazione pod" all'interno della directory del tuo progetto, avrai solo un casino di dipendenze, tra ciò che Pod installerà in base al Podfile, e le basi dei tuoi pod proprio nello stesso albero delle cartelle.

Quello che faccio è sviluppare baccelli (che possono o meno dipendere da altri contenitori) separatamente. È anche buona norma non essere nello stesso "spazio di lavoro" di un'app. E puoi sviluppare il tuo pod con un'app demo.

E nella directory dell'app principale, indico il ramo "sviluppo" dei miei pod, nel Podfile. Quindi, l'app si sta sviluppando con le dipendenze sui pod, come se questi pod fossero pubblicati ufficialmente. Tranne che sono semplicemente in dev pure.

Ti costringe, ovviamente, ad avere le cose separate, il che non è molto bello quando devi cambiare qualcosa nel codice di un pod per la tua app.

Due possibilità (nessuna veramente bella). Innanzitutto, cambia il pod, quindi crea un "aggiornamento pod" nella cartella dell'app.

In secondo luogo, giocare con il codice pod direttamente nell'area di lavoro dell'app (il codice pod è stato importato dal comando di aggiornamento pod). E una volta soddisfatti, eseguire il porting delle modifiche al codice pod originale per il commit.

Un sacco di avanti e indietro, ma non ho trovato di meglio.