Come utilizzare il progetto Xcode e il target per gestire i prodotti?

Sembra che tu stia parlando dell'uso di Xcode per creare una sorta di linea di prodotti software . Ho fatto qualcosa del genere prima rispetto al white-labeling di un prodotto - quindi non c'erano modifiche al codice tra prodotti, solo risorse diverse.

Il mio approccio sarebbe definire un obiettivo diverso per ciascun prodotto, indipendentemente dal fatto che siano nello stesso progetto o meno. Xcode gestisce abbastanza bene le dipendenze tra diversi progetti, quindi è possibile definire facilmente più progetti che stabiliscono le loro dipendenze e utilizzare xcconfig file [*] per mantenere i dettagli di configurazione che devono essere uguali per tutte le destinazioni. È più semplice farlo dal punto di vista del controllo della versione, per ridurre la possibilità che le persone che lavorano su prodotti diversi debbano modificare lo stesso file di progetto.

Inserisci il codice che entra in tutti i prodotti nel proprio target (libreria statica) e includi quella destinazione come dipendenza dagli altri target. Allo stesso modo, se ci sono risorse condivise tra tutti i progetti, crea un target "bundle" che include quelle risorse condivise.

[*] Un file xcconfig è un file di testo semplice contenente le impostazioni di generazione Xcode. Se più di uno dei tuoi progetti contiene obiettivi che dovrebbero utilizzare le stesse impostazioni di build, puoi basare tutti quei target sullo stesso file .xcconfig in modo che le impostazioni siano definite nello stesso posto.

Gli obiettivi all'interno di un singolo file di progetto sono in genere strettamente correlati. Ad esempio, se si dispone di un prodotto che raccoglie dati e che ha diversi componenti correlati, DataCollector, DataCollectorAdministrator e DataCollectorLibrary, tali componenti potrebbero essere tutti target nello stesso progetto. Inoltre, potresti avere obiettivi in quel progetto per cose come test unitari e persino documentazione.

Probabilmente non avresti un obiettivo per un prodotto per lo più indipendente, BaseballStatsGuru, nel tuo progetto DataCollector. Dovresti utilizzare un file di progetto diverso per questo, perché è davvero un prodotto completamente diverso, anche se utilizza DataCollectorLib come uno dei suoi componenti. Anche se si tratta di un progetto diverso, vuoi comunque ricreare BaseballStatsGuru ogni volta che cambia DataCollectorLib, quindi utilizza sempre il codice più recente. Va bene - puoi aggiungere il progetto DataCollector al progetto BaseballStatsGuru come dipendenza.

C'è persino un tipo speciale di bersaglio chiamato "Aggregato":

Aggregatefaunulteriorepassoavanti:untargetaggregatononhaunprodottodisuaproprietà-esistesoloperchépossaesseredipendentedaaltritargetdibuild.Quandosicreaunobiettivoaggregato,vengonocreatituttiitargetdacuidipende(senonsonogiàaggiornati).Quindi,potresticreareunsingoloprogettoubercheincludatuttiituoialtriprogetticomesottoprogettiechedipendadaloro.L'obiettivodiquelprogettosarebbesemplicementeunobiettivoaggregatochedipendedagliobiettividituttiisuoisottoprogetti.L'utilizzodiunsistemacomequestotidàlapossibilitàdicreareun'interaseriediprodotticonunsingolocomando.

Notachequestononèesattamentenuovo-puoifarelastessacosaconimakefilesevuoi.

Inpractice,isanyoneefficientlyusingthisXcodebuilt-instructuretomanagecodeandproducts?

Certo.Sialacapacitàdiavereobiettividiversichedicrearedipendenzetragliobiettivisonomoltoimportanti.Nonsonosicurodicomecaratterizzareillivellodi"efficienza", ma puoi scommettere che avere Xcode come gestire le dipendenze è molto più facile e più affidabile di cercare di farlo a mano.