ObjC: Come compilare una libreria statica che include classi opzionali che dipendono da una libreria di terze parti

Question

Sto cercando di trovare il modo migliore per impacchettare una libreria statica (chiamiamola Lib1) che include una classe opzionale (ad esempio, ClassA), che a sua volta richiede una seconda libreria statica (Lib2). In altre parole, Lib2 è necessario solo se si fa riferimento a ClassA nel codice del progetto. Le cose sembrano funzionare bene, a meno che Lib1 non venga usato in un progetto che non usa ClassA (e quindi non include Lib2), ma richiede il flag link -ObjC (a causa di altre dipendenze del progetto, non mie).

sto cercando di trovare una una soluzione facile per i seguenti tre scenari:
1) progetto prevede la mia lib statica, non usa la classe facoltativa, non specifica il flag -ObjC
2) progetto include la mia lib statica, NON usa la classe opzionale, ma richiede -ObjC flag
3) progetto include la mia libreria statica statica + seconda lib, e DOES usa la classe opzionale (non ci interessa il flag -ObjC a questo punto)

C'è un flag linker là fuori per rimuovere la mia classe opzionale dall'app finale del progetto in modo che non richieda la seconda lib statica? Immagino che le mie altre alternative siano di rilasciare più versioni della mia lib statica, una che include la classe di opzioni (la scelta standard), una che non lo fa (l'alternativa, per i progetti con requisiti ObjC), o magari fornire un file stub, che fornisce implementazioni vuote di tutte le classi necessarie dalla seconda libreria statica? Sembra che potrebbe essere un problema comune nel mondo delle librerie statiche ... esiste una best practice per questo scenario?

Grazie!

---

Soluzione:

1) suggerire ai miei utenti -ObjC che usano -force_load invece. (grazie Rob!)
2) Per gli utenti che non possono fare 1, avrò una build alternativa che non include ClassA

Answer 1

La pratica migliore è sempre quella di avere il collegamento binario finale di tutte le librerie statiche richieste . Non si dovrebbe mai raggruppare una libreria statica in un'altra. Non dovresti assolutamente mai raggruppare una libreria statica ben conosciuta (cioè open source) in una libreria statica che spedisci. Questo può creare incredibili mal di testa per il consumatore finale perché possono finire con più versioni dello stesso codice. Rintracciare i bug che possono venire da questo è follemente difficile. Se sono fortunati, avranno solo errori di compilazione confusi. Se sono sfortunati, il loro codice si comporterà in modi imprevedibili e arresti anomali casuali.

Spedire tutte le librerie statiche separatamente. Dì ai tuoi clienti quali hanno bisogno di collegare per varie configurazioni. Cercare di evitare ciò rende le loro vite difficili.

Alcune altre discussioni che possono essere utili:

• Duplicate Symbol Error: SBJsonParser.o? (Esempio di un cliente che ha incontrato un venditore di fare questo a lui)
• Linking static libraries, that share another static library
• Why don't iOS framework dependencies need to be explicitly linked to a static library project or framework project when they do for an app project?

---

Il flag -ObjC dovrebbe impedire la rimozione automatica di ClassA interamente, se usato o meno (vedere TN1490 per ulteriori dettagli).

Se ClassA non viene mai utilizzato, tranne in alcune circostanze e si desidera risparmiare spazio, è consigliabile spostare ClassA nella propria libreria statica. O utilizzare #ifdef per compilarlo condizionatamente.

In alternativa, è possibile rimuovere il flag e utilizzare -force_load per caricare individualmente tutte le unità di compilazione di sola categoria (che è il problema -ObjC utilizzato per indirizzare).