2013-05-08 12 views
26

Sto riscontrando problemi nel compilare correttamente lo spazio di lavoro con Cocoapods. Ci sono 3 progetti nello spazio di lavoro, ognuno con il proprio obiettivo:Configurazione di Cocoapods con una libreria statica esistente e un'applicazione iOS

  1. libPods - Cocoapods libreria statica con tutte le dipendenze esterne
  2. LIBCOMMON - La mia libreria statica dove tengo tutti i miei codice condiviso (basi controllore, networking codice, comune interfaccia utente, ecc)
  3. myApp - la mia applicazione iOS

Sia LIBCOMMON e myApp richiedono le dipendenze esterne dalle libPods. Inizialmente ho pensato che avrebbe funzionato in questo modo:

  1. libPods costruisce
  2. link LIBCOMMON contro libPods e costruisce
  3. link MyApp con LIBCOMMON e costruisce

In questo scenario LIBCOMMON "possiede" i baccelli , e poi poi myApp si limita a link a libCommon come ho sempre fatto pre-Cocoapods ... ma apparentemente le librerie statiche non amano essere collegate con librerie statiche (ho un sacco di errori dinamici di libreria). Ho letto su un problema github da qualche parte che invece dovrei creare libPods e libCommon e quindi myApp dovrebbe collegarsi a entrambe le librerie. In questo momento il mio podfile simile a questa:

workspace 'MyApp.xcworkspace' 
platform :ios, '5.0' 

link_with ['Common', 'MyApp'] 

target 'MyApp' do 
    xcodeproj 'MyApp.xcodeproj' 

    pod 'AFNetworking',    '1.1.0' 
    pod 'TTTAttributedLabel',   '1.6.0' 
    pod 'JSONKit',     '1.5pre' 
    pod 'Reachability',    '3.1.0' 
end 

Con questa impostazione, myApp possiede tutti i baccelli, e poi nel LIBCOMMON costruire impostazioni a specificare il percorso per le intestazioni pod. Questo va bene fino a quando non cerco di usare una delle classi in libCommon. Una volta che lo faccio, ottengo uno di quegli errori _OBJC_CLASS_$_Blah (che mi dice che anche se le intestazioni sono disponibili, non è ancora collegata correttamente). Quando provo a collegare manualmente libCommon in "Build Phases" ottengo un sacco di errori di simboli duplicati (che mi lascia credere che sia già collegato?). Che diamine?

Qual è il modo per farlo correttamente e come dovrebbe essere il mio podfile?

risposta

10

CocoaPods crea un target radice implicito che per default collega con il primo obiettivo del progetto. Mentre stai creando un altro obiettivo e l'opzione link_with non è ereditata dalle definizioni di target per bambini, il tuo set-up non funziona. Per rendere l'opzione link_with puoi spostarla all'interno del blocco della definizione del target MyApp.

Poiché l'obiettivo comune si collega con i pod, se si collegano quelli con MyApp, si verificherà l'errore di simboli duplicati quando l'app si collega a Common. In questo caso devi solo rendere le intestazioni disponibili per l'obiettivo MyApp. Questo è semplice da fare, ma non esiste un DSL adeguato, quindi per il momento è un po 'hacky come soluzione (ma supportato).

workspace 'MyApp.xcworkspace' 
platform :ios, '5.0' 

target 'Common' do 
    pod 'AFNetworking',    '1.1.0' 
    pod 'TTTAttributedLabel',   '1.6.0' 
    pod 'JSONKit',     '1.5pre' 
    pod 'Reachability',    '3.1.0' 

    target 'MyApp', :exclusive => true do 
    xcodeproj 'MyApp.xcodeproj' 
    end 
end 
+0

Non ho idea di come siate così veloci a rispondere ai cocoapodi, Fabio, ma solo una nota che è molto apprezzata! Ho avuto un problema simile prima e l'opzione 'esclusiva' lo risolve. – Stew

+0

Ho impostato come suggerito e la destinazione MyApp viene compilata correttamente finché non tento di utilizzare una classe da Common (ad esempio aggiungendo questa riga: MyObject * objectFromCommon = [[MyObject alloc] init]; genera un _OBJC_CLASS_ $ Errore _MyObject). L'evidenziazione di sintassi/sintassi è comunque valida, il che mi porta a credere che le intestazioni siano disponibili ma la lib non è ancora collegata. Pensieri? – user2393462435

+0

@ user2393462435, è necessario collegare manualmente il target 'Common' con il target' MyApp' nella fase di costruzione del framework (CocoaPods non gestisce i target). – Fabio

5

La soluzione che ho adottato per questa situazione è la seguente:

Ho creato la Podfile molto semplicemente:

workspace 'MyApp.xcworkspace' 
platform :ios, '5.0' 

xcodeproj 'Common.xcodeproj' 

pod 'AFNetworking',    '1.1.0' 
pod 'TTTAttributedLabel',   '1.6.0' 
pod 'JSONKit',     '1.5pre' 
pod 'Reachability',    '3.1.0' 

target 'MyApp' do 
    xcodeproj 'MyApp.xcodeproj' 
    # specific dependencies 
end 

In questo modo il lib comune e MyApp siano impostati correttamente usare tutte le dipendenze. Tuttavia, questo causerà comunque simboli duplicati. Il modo per aggirare questo è semplicemente eliminare libPods.a dalla fase di costruzione del progetto comune.Questo va bene perché in realtà non vogliamo collegarci alla lib statica di Cocoapods alla nostra lib statica. Tutte le dipendenze corrette verranno collegate durante la creazione dell'app e tutti i percorsi di intestazione corretti verranno impostati nei file .xccconfig, in modo che Xcode/AppCode continui a fornire tutti i completamenti automatici e tutto verrà compilato.

È necessario eliminare libPods.a ogni volta che si esegue pod install che è un po 'un problema, ma potrebbe essere una sofferenza migliore rispetto alla gestione manuale di tutte le dipendenze.

Aggiornamento: Sto lavorando su questo mentre scrivo e ho appena notato che è importante non utilizzare i Linker Flags Cocoapods impostati nella libreria statica. Per impostazione predefinita, il mio lib statico aveva scavalcato il loro valore senza valore, ma Cocoapods mette in guardia contro questo e ti consiglia di usare $ (ereditato). Ignoralo.

+0

Sei a conoscenza di un modo per automatizzare la rimozione? Voglio aggiungerlo in modo che il mio server di build possa fare un 'pod install' prima di ogni build. – Wilmar

+0

Come si risolve questo se si hanno tre progetti nella stessa cartella. "MyApp-Core", "MyApp-iOS" e "MyApp-Mac"? – Sunkas

+0

Sto riscontrando un problema in cui si dice "Nessun file o directory" per Podfile.lock o Manifest.lock. Inoltre, "la sandbox non è sincronizzata con Podfile.lock" –

Problemi correlati