Frage In einem Xcode 4-Arbeitsbereich kaskadiere ich Build-Einstellungen und -Konfigurationen in Teilprojekte


Überblick

Ich verwende statische Bibliotheken und Xcode 4-Arbeitsbereiche, um Modularität in der iOS-Entwicklung zu erreichen, eine zunehmend gebräuchliche Technik. Zum Beispiel könnte ich einen Arbeitsbereich haben, der ein App-Projekt und ein Bibliotheksprojekt enthält1:

Workspace with App & Library

Sie würden dann ein Schema haben, um diese zu bauen, die ungefähr so ​​aussahen:

Scheme

Was ich tun möchte ist, dass die "App build" die "Library build" steuert, die sie initiiert, auf mindestens zwei Arten:

  1. Ordnen Sie App-Konfigurationen (z. B. Debug, AdHoc) beliebigen Bibliothekskonfigurationen zu

  2. Das Durchlaufen einer Teilmenge von -D definiert und / oder spezifiziert diese für den Bibliotheksaufbau.

Ich werde mit jedem von ihnen in ihrem eigenen Abschnitt befassen, aber es lohnt sich ein paar Erläuterungen zu machen.

Erläuterungen

  • Ich benutze App / Library hier als einen einfachen Proxy für jede Superprojekt / Subprojekt-Beziehung, die Sie haben können.

  • Nach dem, was ich gesehen habe, scheinen eingebettete Xcode 3-Teilprojekte in Xcode 4 nicht anders zu funktionieren als die "Peers" im Arbeitsbereich. Ich würde mich gerne irren.

  • Ich weiß, dass ich fast alles mit einer "Run Build Script" -Bauphase und xcodebuild machen könnte. Aber ich versuche hier innerhalb des Systems zu arbeiten, wo die Abhängigkeiten im Schema spezifiziert sind und ansonsten etwas lose gekoppelt sind.

  • Die Bibliothek existiert nicht nur für dieses Projekt, Sie können sie also nicht beliebig mit dem für den Build dieser App spezifischen Junk-Code laden oder auf die App oder den Workspace verweisen. Für den allgemeinen Fall schließt dies die Einbeziehung der statischen .xcconfig-Datei aus dem App-Projekt aus, um Build-Informationen von der App an die Bibliothek zu übermitteln.

  • Der Aufbau der Bibliothek außerhalb des Arbeitsbereichs bringt zu viel Opfer, keine Option.

Konfigurationszuordnung

Wie ich es verstehe, wird das Erstellen einer bestimmten App-Konfiguration:

  1. Wenn eine Konfiguration in der gleichnamigen Bibliothek vorhanden ist, wird die Bibliothek mit dieser erstellt.
  2. Andernfalls wird die aktive Konfiguration der Bibliothek erstellt, wie in der Projektdatei der Bibliothek angegeben.

Nach meinem Wissen, ohne auf den oben erwähnten run-build-script-Hack zurückzugreifen, ist das der Umfang der Kontrolle, die man über Teilprojekt-Build-Konfigurationen hat. Bitte sag es mir anders.

Idealerweise könnte ich (im Schema vermutlich) angeben:

AppConfigA -> LibConfig1
AppConfigB -> LibConfig2

Während Debug, AdHoc und Release möglicherweise die einzigen Konfigurationen sind, die jemals verwendet werden, sind komplexe Projekte oft überfordert.

Definiert

Ich habe den Weg noch nicht gefunden -D definiert vom App-Build bis zur Bibliothek, ohne auf xcodebuild zurückzugreifen, das beispielsweise eine .xcconfig-Datei enthalten kann.

Auf die Build-Einstellungen der App kann in der Bibliothek Build Run-Build-Script-Phase zugegriffen werden. Dies führt jedoch zu einer Abhängigkeit in der Bibliothek des App-Projekts, die aus gutem Grund verboten ist (vgl. Erläuterungen). Aber selbst dann habe ich keine Möglichkeit gefunden, diese Einstellungen zu verwenden, um den Build der Library direkt zu steuern (viel2).

So verrückt könnte es nur sein ...

Ein Schema, das mir während des Schreibens einfallen würde, wäre:

  1. Die Bibliothek basiert ihre Build-Konfigurationen auf einem leeren (Dummy) LibraryExternals.xcconfig Datei innerhalb eines eigenen Projekts.

  2. Eine Bereinigung der Bibliothek löscht diese Datei. Ein eigenständiger Build der Bibliothek erstellt einen leeren, wenn er nicht bereits existiert.

  3. Diese Datei wird von einer App Build run-build-script-Phase überschrieben und enthält alles, was die App mit dem Library-Build kommunizieren möchte.

Scheint irgendwie kompliziert, aber ich suche gerade nach etwas. Ich werde das zu einer Antwort drängen, wenn nichts besseres kommt.


1 Die gezeigten Anwendungen sind Max OS X. Ich finde Kommandozeilen-Apps für einfachere Tests. Gleiches gilt.

2 Vgl. Info.plist preprocessing, über die ich während dieser Untersuchung erfahren habe.


16
2017-12-14 17:58


Ursprung


Antworten:


Wenn Sie Ihre Projektstruktur so ändern, dass ein einzelnes Projekt mit mehreren Zielen verwendet wird, werden die Buildeinstellungen jedes Ziels automatisch vom Projekt übernommen. Von dort können Sie ändern, welche Sie anders sein möchten, oder wählen Sie eine individuelle Einstellung und drücken Sie die Löschtaste, um sie auf die Vorgabe zu setzen, die vom Projekt angegeben wird.


0
2017-08-29 16:06