Ich habe einen Xcode 7.3 Arbeitsbereich mit drei Projekten, App, FrameworkA und FrameworkB. Jedes Projekt hat ein einziges Ziel. Dies ist iOS, also sind die Framework-Ziele Cocoa Touch Frameworks, dh Frameworks, die dynamisch verknüpfte, gemeinsam genutzte Bibliotheken enthalten.Wie Xcode Projektabhängigkeiten mit verschiedenen Buildkonfigurationen festlegen?
App hängt von Framework A ab, das von Framework B abhängt. Diese Abhängigkeiten funktionieren, sofern A korrekt mit dem Buildprodukt von B verknüpft ist und die App ordnungsgemäß mit Frameworks A und B verknüpft und eingebettet ist (weil Sie nicht haben können) Ein Framework, das ein anderes einbindet, scheint ein Anwendungspaket zu verbinden und direkte und transitive Abhängigkeiten einzubetten.)
Aber hier ist mein Problem. Frameworks A und B haben die üblichen Build-Konfigurationen Debug und Release. App hat eine zusätzliche Erstellungskonfiguration, LocalRelease, die durch die Build-Aktion "Build" ausgelöst wird und zum Erstellen eines optimierten Builds (wie Release) verwendet wird, aber Code, der mit einer Entwickleridentität (wie Debug) signiert ist.
Wenn ich versuche, App mit dieser LocalRelease Build-Konfiguration zu bauen, bricht dies den Build, da es die Abhängigkeiten von Frameworks A und B durchbricht. Ich glaube, das liegt daran, dass diese Frameworks keine LocalRelease-Buildkonfigurationen haben Erstellen Sie Produkte in einem LocalRelease-iphoneos-Ordner, so wie es mit App tut.
Also meine enge Frage ist, wie konfiguriere ich Build-Einstellungen, so dass ein Projekt mit einem Nicht-Standard-Build-Konfigurationsname (wie LocalRelease) kann von anderen Projekten, die nur die Standard-Build-Konfiguration Namen verwenden? Ich hoffe, es gibt eine einfache Möglichkeit, dies zu tun, die keine Skripte oder xcconfig-Dateien hinzufügen, aber wenn diese notwendig sind, würde ich gerne verstehen, warum.
Und meine breitere Frage ist, ist es in der Regel eine schlechte Idee, zusätzliche Build-Konfigurationen einzuführen, weil sie keine reibungslose Interaktion von Abhängigkeiten zwischen Projekten in einem gemeinsamen Arbeitsbereich erlauben? Ich wurde dazu gebracht, diese dritte Konfiguration zu definieren, weil ich einen optimierten lokalen Build wollte, ich wollte kein neues Schema definieren, und ich wollte, dass der Build-Typ durch die verschiedenen Build-Aktionen (run, profile, release) ausgedrückt wird ein einziges Schema.
Aber vielleicht war das der falsche Weg, es zu tun. Solange Build-Konfigurationsnamen Build-Produktverzeichnispfade steuern und abhängige Projekte die Build-Produkte des jeweils anderen in einem freigegebenen Verzeichnis suchen müssen, scheint die Einführung eines nicht standardmäßigen Buildkonfigurationsnamens in ein Projekt die Zusammenarbeit zu unterbrechen abhängig von anderen Projekten.