Ich habe einen Xcode 7.3-Arbeitsbereich mit drei Projekten, App, FrameworkA und FrameworkB. Jedes Projekt hat ein einzelnes Ziel. Dies ist iOS, daher sind die Framework-Ziele Cocoa Touch Frameworks, dh Frameworks, die dynamisch verknüpfte gemeinsam genutzte Bibliotheken enthalten.

App hängt von Framework A ab, das von Framework B abhängt. Diese Abhängigkeiten funktionieren, sofern A eine ordnungsgemäße Verknüpfung mit dem Build-Produkt von B herstellt und die App eine ordnungsgemäße Verknüpfung mit den Frameworks A und B herstellt und diese einbettet (da Sie kein einziges Framework einbetten können) Zum anderen muss ein Anwendungspaket direkte und transitive Abhängigkeiten verknüpfen und einbetten.)

Aber hier ist mein Problem. Frameworks A und B haben die üblichen Build-Konfigurationen Debug und Release. Die App verfügt über eine zusätzliche Build-Konfiguration, LocalRelease, die durch die Build-Aktion Run ausgelöst wird und zum Erstellen eines optimierten Builds (wie Release), aber mit einer Entwickleridentität (wie Debug) signiertem Code verwendet wird.

Wenn ich versuche, eine App mit dieser LocalRelease-Build-Konfiguration zu erstellen, bricht dies den Build ab, da die Abhängigkeiten von Frameworks A und B aufgehoben werden. Ich glaube, das liegt daran, dass diese Frameworks keine LocalRelease-Build-Konfigurationen haben, weshalb Xcode ihre Build-Produkte niemals einfügt ein LocalRelease-iphoneos-Ordner, wie es mit App.

So lautet meine enge Frage: Wie konfiguriere ich Build-Einstellungen, damit ein Projekt mit einem nicht standardmäßigen Build-Konfigurationsnamen (wie LocalRelease) von anderen Projekten abhängen kann, die nur die standardmäßigen Build-Konfigurationsnamen verwenden? Ich hoffe, es gibt eine einfache Möglichkeit, dies zu tun, bei der keine Skripte oder xcconfig-Dateien hinzugefügt werden müssen, aber wenn diese erforderlich sind, würde ich gerne verstehen, warum.

Und meine allgemeine Frage lautet: Ist es im Allgemeinen eine schlechte Idee, zusätzliche Build-Konfigurationen einzuführen, da sie keine reibungslose Interaktion von Abhängigkeiten zwischen Projekten in einem gemeinsam genutzten Arbeitsbereich ermöglichen? Ich wurde zur Definition dieser dritten Konfiguration geführt, weil ich einen optimierten lokalen Build wollte, kein neues Schema definieren wollte und die Wahl des Build-Typs durch die verschiedenen Build-Aktionen (Ausführen, Profil, Release) von ausgedrückt werden sollte ein einzelnes Schema.

Aber vielleicht war das der falsche Weg. Solange Build-Konfigurationsnamen die Verzeichnispfade der Build-Produkte antreiben und abhängige Projekte die Build-Produkte in einem gemeinsam genutzten Verzeichnis suchen müssen, scheint die Einführung eines nicht standardmäßigen Build-Konfigurationsnamens in ein Projekt die Interoperation mit zu stören abhängig von anderen Projekten.