Ich schreibe ein Skript, um den iOS-Teil eines Phonegap-Projekts zu archivieren. Das Skript löscht das Verzeichnis, in dem sich das Projekt befindet, und füllt es dann mit dem neuesten Code aus der Quellcodeverwaltung auf. Ich starte dann $ phonegap local build ios , um das Projekt zu erstellen. Um das Projekt zu archivieren, müssen jedoch seine Schemata definiert werden. Ich habe versucht, das Projekt über die Befehlszeile zu erstellen, aber ich bekomme die Nachricht ** BUILD FAILED **. Im Moment habe ich den Code geöffnet das xcode-Projekt (der einzige Weg, den ich gefunden habe, um die Schemata zu definieren) und dann für 30 Sekunden schlafen, während ich darauf warte, dass xcode seine Magie funktioniert. Meine Frage ist, wie kann ich entweder das Öffnen von xcode simulieren oder das Schema von der Kommandozeile aus anders definieren.
Vielen Dank im Voraus für jede Hilfe.
Dies ist eine absolut faire Frage, da Xcode-Schemata etwas weniger als gründlich dokumentiert sind und Systeme dieses Gefühl haben, etwas magisch zu sein, bis Sie sehen, wie sie sich als Ganzes in den Build-Prozess einklinken.
Aufgrund der von Ihnen gewünschten Problemumgehungen klingt es so, als müssten Sie ein Schema auf "Freigegeben" heraufstufen, damit automatisierte Tools (oder andere Entwickler) Ihr Projekt nicht erst öffnen und warten müssen, bis Xcode automatisch gestartet wird. Generiere das Standardschema. Dies ist eine ganz normale Frage von Entwicklern, die versuchen, ihre Xcode-Projekte mit Continuous Integration-Systemen oder mit anderen Befehlszeilentools zu arbeiten, die auf einem Xcode 4- oder Xcode 5-Projekt arbeiten. Die gute Nachricht ist, dass es Xcode-native Möglichkeiten gibt, Ihr Projekt zu konfigurieren, ohne auf unordentliche oder fehleranfällige Workarounds zurückgreifen zu müssen.
TL; DR-Version:
Das Xcode-Standardverhalten für Schemas besteht darin, sie als entwicklerspezifische Einstellung zu behandeln und nicht mit anderen Entwicklern oder Tools zu teilen. Wir müssen das Schema Ihres Projekts für "freigegeben" bekannt machen und diese Änderungen Ihrem Versionskontrollsystem übertragen:
Dadurch wird ein einzelnes Schema für alle Entwickler freigegeben, die dieses Projekt verwenden, unabhängig vom OS X-Benutzernamen, und es wird so eingerichtet, dass unbeaufsichtigte Builds über xcodebuild oder das gewünschte Build-Tool mit einem Schema arbeiten können.
... Und jetzt, auf die längere Antwort für die Neugierigen
Zuerst ein bisschen Hintergrund, bevor wir uns Ihren direkten Fragen zuwenden:
Ziel: Die App, die statische Bibliothek, das Bundle oder allgemeiner das Produkt, das aus Quellcode, Assets, Plists, Build-Einstellungen und anderen im Projekt enthaltenen Dateien erstellt wird. Dieses "Produkt" wird generiert, wenn eine Build-Operation entweder über die Xcode-Schaltfläche "Ausführen" oder über das Befehlszeilen-Tool xcodebuild
Build-Konfiguration: Ein benannter Satz von Build-Einstellungen, der durch ein lesbares Label identifiziert werden kann. Standardmäßig beginnen alle Xcode-Projekte mit einer "Debug" -Konfiguration, die Build-Ziele mit der größten Transparenz erzeugt, die den Entwicklern beim Debuggen ihrer Anwendungen helfen, und einer "Release" -Konfiguration, die den resultierenden Build dieser Diagnoseinformationen streift und den Build zur Reduzierung optimiert seine Größe. Einige Entwickler entscheiden sich dafür, zusätzliche Konfigurationen basierend auf den Anforderungen ihres Teams zu erstellen: "Ad-Hoc" wird möglicherweise erstellt, damit die Einstellungen für Signing Identity und Provisioning Profile geändert werden können, um die App für die Installation über ein Ad-Hoc Provisioning-Profil zu signieren. "AppStore" oder "Distribution" sind andere gebräuchliche benutzerdefinierte Build-Konfigurationen, die man in anderen Projekten sehen kann.
Aktion: Eine Reihe verwandter Aktivitäten, die verschiedene Phasen unterstützen, die bei der Entwicklung, Diagnose und Prüfung eines Produkts eine Rolle spielen. Zum Zeitpunkt des Schreibens gibt es sechs Aktionen: "Erstellen", "Ausführen", "Testen", "Profil", "Analysieren" und "Archivieren". Als Entwickler werden Sie am häufigsten "Build" und "Run" verwenden.
Build-Schema: Eine Xcode 4-Erfindung zum Verwalten von Projekt-Build-Ziel-Abhängigkeiten, Build-Parallelisierungsoptionen für ein bestimmtes Build-Ziel. Jedes Schema ermöglicht es einem Entwickler, für jede Aktion ("Erstellen", "Ausführen" usw.) des Lebenszyklus eines Projekts genau eine Build-Konfiguration (z. B. "Debuggen" oder "Release") auszuwählen und andere zugeordnete Verhaltensweisen oder Optionen zu definieren mit dieser spezifischen Aktion. Mit der Aktion "Profil" in einem Schema kann der Entwickler z. B. auswählen, welches Diagnoseinstrument standardmäßig beim Profilerstellungscode in Instruments.app.
geladen wirdLassen Sie uns mit diesen Definitionen auf Ihre Fragen zurückkommen:
Wie kann ich entweder das Öffnen von xcode simulieren oder das Schema von der Befehlszeile aus anders definieren?
Sehr einfach: Sie müssen das auch nicht tun, es gibt einen Xcode-nativen Mechanismus, um Schemata zur Verfügung zu stellen und wir müssen nur eine kleine Schema-Rekonfiguration vornehmen, um Sie zum Laufen zu bringen und dann diese Änderungen an die Versionskontrolle zu übergeben ( Ich werde dies für den Rest dieser Antwort als "SCM" bezeichnen.
Das Verhalten, dem Sie gegenüberstehen, ist das Standard-Verhalten von Xcode, wenn es um persistente Projekteinstellungen geht.Viele Dinge werden standardmäßig als entwicklerspezifische Einstellungen betrachtet und befinden sich in einer Reihe von Dateien, die dem spezifischen Benutzernamen des Kontos zugeordnet sind, das das Xcode-Projekt selbst geöffnet hat (mehr dazu in Kürze). Die Richtlinie, die diese Einstellungen regelt, könnte auf die Regel heruntergebrannt werden, dass Xcode-Einstellungen als "Entwickler privat" betrachtet wurden, bis sie explizit als "freigegeben" deklariert wurden. Obwohl dies in Versionen von Xcode vor Xcode 4 vorhanden war, verursachte dieser Ansatz erst bei der Einführung von Schemas als primärem Tool zum Aufrufen von Builds Entwicklungsteams und ihre Probleme mit der Continuous Integration System.
Schemas kamen und konsolidierten eine große Anzahl von Einstellungsbildschirmen früher Versionen von Xcode in einem einzigen Editorfenster, in dem ein Entwickler die Einstellungen auf höchster Ebene für jede der verschiedenen Aktionsphasen der App betrachten konnte:
Diese Einstellungen verursachen in jedem Fall einen Kaskadeneffekt - Bei Auswahl einer "Debug" -Konfiguration werden so viele Diagnosedaten in der App gespeichert, dass Entwickler die Ursache von Problemen verfolgen können. Debuggen Sie "spezifische Build-Einstellungen", wie im Build-Ziel selbst konfiguriert, die auch "Debug" -spezifische Skripts ausführen oder "Debug" -spezifische Einstellungen aktivieren können.
Natürlich mussten diese Auswahlen irgendwo leben, damit sie zwischen den Entwicklungssitzungen oder in den seltenen Fällen, in denen Xcode zum Absturz kommt, beibehalten werden konnten. Das Verhalten von "Developer private bis promited" war oberstes Gebot und diese Scheme-Einstellungen wurden im Ordner "xcuserdata" innerhalb der .xcodeproj-Datei selbst beibehalten. - Dies gilt weiterhin für die Projekte, die Teil eines .xcworkspace sind .
Das können Sie in Ihrem eigenen Projekt sehen. Stellen Sie zuerst sicher, dass Sie mit einer sauberen Version Ihres Codes arbeiten, und öffnen Sie dann das Xcode-Projekt oder den Arbeitsbereich, um sicherzustellen, dass Ihre persönliche Version des Standardschemas verfügbar ist, wenn wir Ihre Projektdatei durchgehen:
Abhängig von der Anzahl der Entwickler, die an diesem Projekt beteiligt waren, oder der Anzahl der verschiedenen Maschinen mit unterschiedlichen Benutzernamen, die für dieses Projekt festgelegt wurden, ist es eindeutig möglich, mehr als einen .xcuserdatad-Ordner zu verwenden.
Diese Erkenntnis beginnt, im Kern dessen zu werden, was wir tun müssen - dieses Schema aus dem entwicklerspezifischen xcuserdata-Ordner in etwas unter allen Entwicklern zu migrieren, die automatische Schema-Generierung zu deaktivieren, um zu verhindern, dass andere in die falle in der Zukunft und übertrage diese Änderungen zurück zu deinem SCM. Wechseln Sie zurück zu Xcode, lassen Sie uns ein paar Dinge neu konfigurieren:
Wechseln Sie zurück in Ihr Finder-Fenster und gehen Sie zwei Ebenen nach oben, um zum Inhalt des Ordners .xcodeproj (der Ordner mit dem Ordner "xcuserdata") zurückzukehren. Beachten Sie, dass Sie jetzt einen Ordner "xcshareddata" haben. Dieser Ordner enthält einen Ordner "xcschemes", der das Schema enthält, das wir gerade freigegeben haben, und das .xcscheme in unserem eigenen Ordner "xcuserdata" ist nun verschwunden.Wir haben soeben Ihr privates Programm als ein gemeinsames, öffentliches Programm vorgestellt, das allen Entwicklern und Tools zur Verfügung steht, auch denen, die das Xcode-Projekt nie direkt gestartet haben.
Alle Änderungen, die wir vorgenommen haben (es werden einige neue Ordner und Dateien vorhanden sein!), zurück in Ihren SCM übertragen, damit alle die gleichen Konfigurationsänderungen bei der nächsten Aktualisierung ihres Quellcodes erhalten!
Wenn Sie phonegap das nächste Mal ausführen, wird Ihr Checkout wie angegeben zurückgesetzt, aber da Sie ein Schema festgelegt haben, wird es Build-Aktionen geben, mit denen es arbeiten kann.
Schlagen Sie dies und lassen Sie uns wissen, wie die Dinge laufen und wenn Sie auf irgendwelche weiteren Fragen oder Probleme stoßen.
Sie können auch den Rubinstein xcodeproj nützlich finden. Es kann Schemata erstellen, ohne xcode öffnen zu müssen.
Sie können mehr darüber hier lesen.
Speichern Sie für phonegap / cordova das Skript share_schemes.rb in einem Skriptverzeichnis im cordova-Projekt.
%Vor%Fügen Sie dann einen Hook hinzu, um es in Ihrer config.xml auszuführen.
%Vor%Nun müssen Sie xcode nicht öffnen, um Änderungen vorzunehmen, oder Änderungen in Ihrem Plattformordner einchecken. Jedes Mal, wenn Sie die ios-Plattform hinzufügen, wird Ihr Schema von diesem Skript erstellt.
Tags und Links cordova bash xcodebuild