Xcode 4 und verschachtelte Projekte - Header-Dateien nicht gefunden
Ich habe unzählige Probleme mit Xcode 4 und verschachtelten Projekten, die unter Xcode 3.2 einwandfrei funktionierten. Hier ist eine sehr grundlegende Frage, die ich nicht lösen kann:
Ich baue ein Kakao-Framework, das ein anderes Kakao-Framework erfordert, für das ich die Quelle habe. Also führe ich die üblichen Schritte aus:
- Ziehen Sie die Datei
.xcodeprojDes gewünschten Frameworks in mein Haupt-Framework-Projekt - In meinem Hauptrahmen unter ZIELE> MyFramework> Phasen erstellen> Zielabhängigkeiten: Fügen Sie das Ziel des verschachtelten Projekts hinzu
- Stellen Sie sicher, dass die Headerdateien des verschachtelten Frameworks öffentlich sind
- In Xcode-Einstellungen> Standorte> Erstellungsort Ich habe festgelegt, dass Erstellungsprodukte am Speicherort abgeleiteter Daten platziert werden sollen (empfohlen)
- Der Build-Produktpfad beider Ziele ist auf
${BUILT_PRODUCTS_DIR}Gesetzt und teilt mir mit, dass sie sich am DerivedData befinden/Debug (oder Release) Speicherort - Die Architektureinstellungen für beide Ziele sind identisch
Dann drücke ich [CMD] + B um zu bauen und es sagt mir, dass es die Header-Dateien des verschachtelten Frameworks nicht findet. Wenn ich die Einstellungen überprüfe, enthalten User Header Search Paths den Pfad zu DerivedData/Debug , und im Inneren befindet sich das verschachtelte Framework-Ziel mit den Header-Dateien in Versions/A/Headers .
Ich sitze hier, hat jemand eine Idee, was ich falsch mache?
Das Problem verschwindet beim Erstellen von Debug, wenn ich die Suchpfade für Benutzer-Header in ${BUILT_PRODUCTS_DIR}/MyFramework.framework/Headers Ändere. Dies funktioniert jedoch nicht beim Erstellen für Distribution, da die Frameworks dann ihre Release-Einstellungen verwenden, die in einem anderen Unterverzeichnis landen ...
Meine vorübergehende Lösung besteht darin, auch eine Distribution Konfiguration für die verschachtelten Projekte zu definieren. Auf diese Weise werden die Header gefunden und der Linker kann erfolgreich verknüpft werden.
Hier ist mein bisher zusammengestelltes Wissen:
Vergiss die ganze public Header-Sache mit Xcode, es ist eine PITA und funktioniert nicht richtig beim Archivieren deiner App. Stellen Sie stattdessen sicher, dass sich alle statischen Bibliotheksheaderdateien auf der Ebene project befinden, und teilen Sie Ihrer App mit, wo sie sich befindet.
Entlasten Sie Ihre Probleme, indem Sie sicherstellen, dass alle Ziele den Namen für die Build-Konfiguration haben (d. H. Den statischen Bibliotheken eine Konfiguration für "AdHoc" und "Bereitstellung" hinzufügen).
Zeigen Sie in den Build-Einstellungen auf Header-Suchpfade (wenn Sie
#include <file.h>Verwenden) oder Benutzer-Header-Suchpfade ( Wenn Sie#include "file.h") in das Verzeichnis des statischen Bibliotheksprojekts verwenden. Wenn das statische Bibliotheksprojekt in Ihrem Anwendungsverzeichnis lautet, verwenden Sie Folgendes:"$(PROJECT_DIR)"( recursive enabled)Wenn Sie ein Verzeichnis haben, das a) das statische Bibliotheksprojekt und b) Ihre App enthält, sollte dies funktionieren:
"$(PROJECT_DIR)/.."( recursive enabled)Wenn das Submodul kompilierte Bibliotheken enthält, setzen Sie Ihre Bibliothekssuchpfade auf:
"$(TARGET_BUILD_DIR)"Stellen Sie sicher, dass für alle verwendeten statischen Bibliotheksprojekte Skip Install
YESfestgelegt ist.Auch hier gilt: keine öffentlichen Header-Dateien (Phasen erstellen "Header kopieren) in einer der statischen Bibliotheken. Andernfalls kann Xcode eine App nicht archivieren.
Stellen Sie sicher, dass Sie Xcode mitteilen, wann die statischen Bibliotheken erstellt werden sollen (siehe in diesem Tech Doc von Apple .
Alte Antwort:
Ich habe immer noch keine echte Lösung für dieses Problem mit statischen Bibliotheken gefunden. Was für mich funktioniert ist:
- Erstellen Sie eine "AdHoc" -Konfiguration für die statische Bibliothek
$(BUILT_PRODUCTS_DIR)zu Benutzerkopfzeilensuchpfaden für die Anwendung hinzufügen (mit recursive markiert) -> wird beim Ausführen der App verwendet- Wählen Sie im Xcode-Menü Product > Build For > Build For Archiving
Dies funktioniert, die App findet die Header-Dateien und erstellt sich selbst. Sie wird in DerivedData // Build/Products/AdHoc-iphoneos/als App-Bundle gespeichert. Nach diese einfache Anleitung (Dead Link) von TestFlightApp.com kann ich diese App in einen IPA packen und verschicken. Durch einfaches Auswählen von Archive findet die App von Xcode die Header nicht wieder, auch wenn sie sich tatsächlich im AdHoc-iphoneos-Build-Verzeichnis befinden.
(Ab Xcode 5.1)
Wenn das Teilprojekt von XCode erstellt wird, werden die Teilprojekt-Header-Dateien in das Erstellungsverzeichnis kopiert. Bei der Archivierung scheint dieses Zielverzeichnis der Kopie nicht zum Suchpfad für Header/Include hinzugefügt zu werden. Gehen Sie zu Ihren Build-Einstellungen und fügen Sie sie hinzu
$(BUILD_ROOT)/../IntermediateBuildFilesPath/UninstalledProducts/include
in die "Header-Suchpfade" für das Schema, das Sie für die Archivierung verwenden.
Wenn Sie nicht sicher sind, welches Schema für die Archivierung verwendet wird, gehen Sie zu Produkt -> Schema -> Schemas bearbeiten und suchen Sie in der linken Spalte nach Archiv.
Stellen Sie sicher, dass Ihr Drittanbieter-Framework Ihrem Hauptprojekt als "Gruppe" hinzugefügt wird, damit Sie es in der Hierarchie Ihres Projekts sehen können ...
Ich hatte das gleiche Problem mit einer Konfiguration namens "Ad Hoc" (gemäß TestFlight-Empfehlung unter http://help.testflightapp.com/customer/portal/articles/402782-how-to-create-an-). ipa-xcode-4 ) und das Hauptprojekt konnten einige der Header der verschachtelten Projekte nicht finden. Ich habe das Projekt in "AdHoc" (keine Leerzeichen) umbenannt und das Problem ist behoben. Anscheinend können Leerzeichen in einigen Fällen die Pfade für die Kopfzeilensuche durcheinander bringen, obwohl ich nicht herausgefunden habe, wann und warum dies passieren könnte.
Ich hatte dieses Problem mit einem verschachtelten Projekt, das eine statische Bibliothek erstellt hat. Ich habe dieses Dokument auf der Website von Apple gefunden, das mir das Leben gerettet hat.
Ich bin so froh, dass ich mich nicht mit den abgeleiteten Datenpfaden herumschlagen musste.
Ich hatte hier das gleiche Problem und konnte das Problem lösen, indem ich "Build Location" so einstellte, dass Build-Produkte an Orten platziert wurden, die von Zielen angegeben wurden.
Ich hatte dieses Problem: Ich konnte sowohl Debug- als auch App Store-Konfigurationen erstellen, aber nicht Ad-hoc. Beim Erstellen von Ad-hoc-Dateien sind Fehler aufgetreten, da die von verschachtelten Projekten benötigten .h-Dateien nicht gefunden wurden.
Es stellte sich heraus, dass in meiner Release-Konfiguration eine abgelaufene Bereitstellung verblieben ist. Ich habe diesen Bereitstellungslink aktualisiert und kann jetzt sowohl Ad-hoc erstellen als auch die Archivfunktion zum Packen verwenden..
Ich habe Stunden gebraucht, um es herauszufinden! Mein Verstand sprang einfach nicht von fehlenden .h-Dateien zu Bereitstellungsfehlern von alleine. =) Möglicherweise ist ein Fehler oder eine Warnung aufgetreten, die sich über die fehlende Bereitstellung beschwert, aber wenn ja, wurde sie unter den Hunderten von Fehlern im Zusammenhang mit .h begraben.
Für mich geschah dies nach einer GIT-Zusammenführung, die viele Konflikte verursachte, von denen einer mit der Projektdatei zusammenhängt. Ich bin mir sicher, dass sich die Struktur der Projektdatei nach dem Zusammenführen geändert hat.
Am Ende ging ich in das Projekt "Build Settings", suchte nach "Always Search User Paths" und wandelte es in Yes um.
Ich denke, die Zusammenführung hat diesen Booleschen Wert in No geändert, daher hat das Projekt nicht an den richtigen Stellen nach den Header-Dateien gesucht.