Ich habe ein iOS-Projekt, das CocoaPods verwendet. Alles lief reibungslos, bis ein anderer Entwickler an demselben Projekt arbeitete. Er hat einige Änderungen vorgenommen (nur Code, soweit ich weiß) und einen neuen Zweig im Repo erstellt. Ich habe seinen Zweig ausgecheckt und versucht, ihn zu erstellen, aber es wird eine Fehlermeldung angezeigt: ASLogger/ASLogger.h-Datei nicht gefunden.
Auch wenn ich das gesamte Projekt lösche und eine neue Kopie mache und "Pods install" verwende. Der Build-Fehler ist immer noch da. Hast du eine Ahnung, wo das Problem liegen kann? Wenn Sie weitere Informationen benötigen, fragen Sie einfach.
Update
Stellen Sie sicher, dass Ihre Podfile
link_with
für Ziele enthält, die keine Konfigurationsdatei enthalten. Nur Kokosapods setzt standardmäßig das erste Ziel ansonsten. z.B.
platform :osx, '10.7'
pod 'JSONKit', '~> 1.4'
link_with 'Pomo', 'Pomo Dev', 'Pomo Tests'
------ Update beenden
Hinweis: Bitte beachten Sie, dass Sie für die folgenden Schritte unter Projekt-> Info-> Konfigurationen nachsehen müssen.
Ich hatte ähnliche Symptome und stellte fest, dass die pods.xcconfig
-Datei nicht in der spezifischen target
enthalten war, die ich erstellen wollte. Einige der anderen Lösungsvorschläge funktionierten für mich, aber diese schien einen Teil des zugrunde liegenden Problems zu lösen.
Die einfache Lösung bestand darin, die Konfigurationsdatei für die Ziele festzulegen, für die kein Satz festgelegt wurde.
Update
Ich habe dies seit meiner ursprünglichen Antwort aktualisiert, die den Downvote erhalten hat, also hoffe ich, dass dies hilft. Und wenn, dann wird es hoffentlich meine Stimme zurückbekommen.
Wenn die Header nicht importiert werden, liegt wahrscheinlich ein Konflikt im HEADER_SEARCH_PATHS
vor. Versuchen Sie es mit $(inherited)
in den Header-Suchpfaden in Ihren Build-Einstellungen, um sicherzustellen, dass alle in der .xcconfig-Datei enthaltenen Suchpfade aus Ihrem CocoaPods abgerufen werden.
Dies sollte bei Konflikten helfen und den Quelltext korrekt importieren.
1.Überprüfen
build-Einstellungen -> Suchpfad -> Suchpfad für Benutzerheader ->
2.Überprüfen Sie den Importstil (KEY POINT), , Wenn Ihre podfile
eingestellt ist
use_frameworks!
In Ihrem File-Bridging-Header.h
sollte dies dem Formatierer gefallen
#import "MBProgressHUD.h"
sonst sollte unten sein
#import <MBProgressHUD.h>
3.Das muss Arbeit sein! vertraue mir
Header-Dateien, du wirst der Tod von mir sein ...
Endlich zum Laufen gebracht (mit Zitaten)
"${PODS_ROOT}/BuildHeaders"
zu dem Eintrag User Headers Search Paths, und überprüfen Sie 'rekursiv'.
Ich fand, dass ${PODS_HEADERS_SEARCH_PATHS}
fehlt und in meinem Entwicklungsgit-Zweig nicht definiert ist. Daher fügte ich "$(SRCROOT)/Pods/Headers/"
für Header-Suchpfade mit rekursiv hinzu
Das ist für mich in Ordnung
Die beiden anderen Antworten haben hier nicht geholfen. Ich habe 2 andere Probleme gefunden, die das Problem beheben könnten:
Die Projekt-> Info-> Konfigurationen im Xcode-Projekt (Ihr Projekt) sollten für Debug, Release (und was Sie haben) auf 'Pods' gesetzt werden. Siehe "Header nicht gefunden - Suchpfade nicht enthalten"
Möglicherweise müssen Sie das Ziel mit dem Befehl link_with verknüpfen. Siehe "Header im statischen Bibliotheksprojekt nicht gefunden"
EDIT Sie können einen Symlink auf diese Weise überprüfen: Erstellen Sie eine Textdatei mit dem Namen 'check' ohne Erweiterung. kopiere diese Zeilen hinein:
file=/Users/youUserName/XcodeProjectName/Pods/BuildHeaders/SVProgressHUD/SVProgressHUD.h
if [[ ! -e $file && -L $file ]]; then
echo "$file symlink is broken!"
else
echo "symlink works"
fi
Gehen Sie dann zum Terminal, wechseln Sie in den Ordner, in dem sich Ihre Prüfdatei befindet, und geben Sie den Typ ein
bash check
Folgendes hat für mich funktioniert:
Wechseln Sie zur Registerkarte "Ziel"> "Build-Einstellungen" und suchen Sie nach der Einstellung "Suchpfade für Benutzerheader".
Setzen Sie diesen Wert auf "$ (BUILT_PRODUCTS_DIR)" und aktivieren Sie das Kontrollkästchen "Rekursiv".
Jetzt sucht das erstellte Ziel im freigegebenen Build-Verzeichnis des Arbeitsbereichs nach den verknüpfbaren Header-Dateien.
====
AKTUALISIEREN
Ich hatte kürzlich ein ähnliches (wenn auch etwas anderes) Problem. Es stellte sich heraus, dass Xcode die Pods nicht finden konnte, weil ich die .xcodeproj
-Datei anstelle der .xcworkspace
-Datei geöffnet hatte. Könnte anderen in der Zukunft helfen.
Wenn keiner der oben genannten Punkte für Sie funktioniert hat und Sie diesen Fehler feststellen, weil Sie gerade use_frameworks!
in Ihrer Pod-Datei gewechselt haben, lesen Sie weiter:
Ich habe alle oben genannten Lösungen ausprobiert und noch viel mehr, bevor ich erfuhr, dass es in meinem speziellen Fall überhaupt nicht um Suchkopfpfade geht. Wenn Sie in Ihrer Pod-Datei zu use_frameworks!
wechseln, müssen Sie keine Frames mehr in Ihren Bridging-Header einfügen. In der Tat wird Xcode den sehr wenig hilfreichen Fehler "Header nicht gefunden" auslösen.
Was Sie tun müssen, ist, alle Importe aus Ihrer Bridging-Header-Datei zu entfernen, und verwenden Sie stattdessen Swift import Module
in Ihren einzelnen Swift-Dateien, so wie Sie es für Swift-Frameworks tun würden.
UND wenn Sie einen der Framework-Header in Ihren Obj-C-Klassen verwenden (in meinem Fall haben wir eine Convenience-Klasse, die FBSDK verwendet hat), müssen Sie sie von einem lokalen in einen globalen Import ändern (dh #import "Module.h"
in #import <Module/Module.h>
) sollte für Sie automatisch abgeschlossen werden, wenn Sie mit dem Eingeben des Frameworknamens beginnen (in meinem Fall <AFNetworking/AFHTTPRequestOperationManager.h>
).
Edit: Ich habe seitdem gelernt, dass ein @import Module
die Dachdatei verwendet, was noch sicherer ist.
Haben Sie versucht, den Cocoapods-Stil zu importieren?
#import <ASLogger.h>
Die Informationen auf der Website sind nicht wirklich klar, ich habe eine Pull-Anfrage eingereicht:
https://github.com/CocoaPods/cocoapods.org/pull/34
Update: Sie haben meine Anfrage gezogen :)
Das Wiki gibt Hinweise, wie Sie dieses Problem lösen können:
Wenn Xcode die Header der Abhängigkeiten nicht finden kann:
Prüfen Sie, ob die Pod-Header-Dateien in Pods/Headers .__ richtig verknüpft sind. und Sie überschreiben nicht die HEADER_SEARCH_PATHS (siehe # 1). Wenn Xcode Sie können sie immer noch nicht finden. Als letzte Möglichkeit können Sie Ihre Importe voranstellen. z.B. #import "Pods/SSZipArchive.h".
Ich war der einzige Entwickler im Team, der das gleiche Problem hatte, es funktionierte perfekt für alle, und mir wurde klar, dass es meine Umgebung sein musste. Ich habe einen git clone
desselben Projekts in einem anderen Verzeichnis ausprobiert und es wurde perfekt kompiliert. Dann wurde mir klar, dass es Xcode-Zwischenspeicher für meinen Projektpfad irgendwo geben musste, dass "irgendwo" der DerivedData-Ordner ist Dein Projekt hat für mich funktioniert.
Sie können den Pfad abrufen und den Ordner sogar im Finder öffnen. Gehen Sie dazu auf:
Xcode -> Einstellungen -> Standorte -> ** DerivedData
Ich werde die folgenden Dinge in meinen Build-Einstellungen aktualisieren und habe keine Fehler erhalten. Um dies zu überprüfen, müssen Sie die Kokosapods aktualisieren.
Build-Einstellungen
Bitcode aktivieren - JA (wenn Sie Bitcode verwenden)
Makropräprozessor - $ (geerbt)
Anderes Linker-Flag - objc, -lc ++, $ (geerbt)
Nur Architektur bauen
Debuggen - Ja
Relese - Nein
Suchpfad
Framework-Suchpfad - $ (geerbt) $ (PROJECT_DIR)
Bibliotheks-Suchpfad - $ (geerbt)
Header-Suchpfad - $ (geerbt)
Wenn Sie nach einem " pod install " oder einem " pod update " Fehler beim Bauen hatten, kann es sein, dass einer Ihrer Pods mit XCode 6.3 erstellt wurde, während Sie noch verwenden eine vorherige Version.
In meinem Fall musste ich mein OSX von Mavericks auf Yosemite aktualisieren, um Xcode 6.3 zu haben und das Problem zu lösen
Ich habe das gleiche Problem, aber die oben genannten Lösungen können nicht funktionieren. Ich habe es dadurch behoben:
Und dann funktioniert es.
für mich war das Problem in Other Linker Flags wert. Aus irgendeinem Grund hatte ich keine Anführungszeichen in Flags wie -l"xml2"
-l"Pods-MBProgressHUD"
.
Ich musste den Zip von git hub herunterladen und die fehlenden Dateien in den Finder unter entsprechenden Pfaden in Pod/ziehen ...
Hier ist ein anderer Grund: Alle Headerpfade schienen in Ordnung zu sein, aber wir hatten immer noch einen Fehler in der vorkompilierten Datei (.pch), als versucht wurde, einen Pod-Header zu lesen
(d. h. #import <CocoaLumberjack/CocoaLumberjack.h>).
Bei der Rohausgabe des Builds bemerkte ich schließlich, dass der Fehler unser Erweiterungsziel für das Überwachungs-OS brach und nicht das Hauptziel, das wir bauten, da wir auch die vorkompilierte .pch-Header-Datei in die Überwachungs-OS-Ziele importierten Dort. Stellen Sie sicher, dass die zugehörigen Watch OS-Zieleinstellungen nicht versuchen, die PCH-Datei zu importieren (insbesondere, wenn Sie den Import aus der Master-Zieleinstellung festlegen, wie ich es getan habe!)
Ich war auf dem GM -Samen von Xcode 5.0 und konnte keine dieser Antworten zur Arbeit bekommen. Ich habe jede einzelne Antwort auf SO zu mehreren verschiedenen Fragen zu Header-Importen mit Cocoapoden ausprobiert.
ENDLICH fand ich eine Lösung, die für mich funktionierte : Ich habe ein Upgrade auf Xcode 5.0 über den Mac AppStore (installiert über dem GM - Startwert) durchgeführt, und jetzt funktionieren die Header-Importe wie erwartet.
Ich hatte auch noch eine Betaversion von Xcode 5 auf meinem System und ich habe auch diese gelöscht. Vielleicht war es eine Kombination der beiden Dinge, aber hoffentlich hilft dies jemand anderem.
Was für mich funktionierte, war die Auswahl des Pod-Projekts, das Finden und Auswählen des Zielframeworks mit dem fehlenden Header im Zielverzeichnis des Pod-Projekts und die Einstellung "Nur aktive Architektur erstellen" unter "Architekturen" in den Build-Einstellungen des Ziels.
Ich habe festgestellt, dass das Einbinden der Bibliothek als Pod-Installation direkt dynamischen Bibliotheken hilft. Zum Beispiel für Firebase:
pod 'RNFirebase', :path => 'path/to/node_modules/react-native-firebase/ios'
Oder für ASLogger:
pod 'ASLogger', :path => 'path/to/node_modules/aslogger/ios' // path to header files
Das Ändern oder Hardcoding von HEADER_SEARCH_PATHS
hat mir nicht geholfen. Wenn der Fehler erneut auftritt, ist es nicht erforderlich, rm -rf node_modules
zu löschen oder die Pod-Datei usw. zu löschen. Ich fand es nützlich, den Cache zu löschen.
Für reaktions-native laufe ich
rm -rf $TMPDIR/react-native-packager-cache-*
rm -rf $TMPDIR/metro-bundler-cache-*
rm -rf $TMPDIR/metro-*
rm -rf $TMPDIR/react-*
rm -rf $TMPDIR/haste-*
rm -rf "$(getconf DARWIN_USER_CACHE_DIR)/org.llvm.clang/ModuleCache"
npm start -- --reset-cache
Für Xcode entferne ich Ordner in ~/Library/Developer/Xcode/DerivedData
Keine der Antworten hat mir geholfen (ich hatte meine Pods mit allen Zielen verknüpft, die korrekte Konfiguration der Konfigurationen, die korrekten Suchpfade "$ (vererbt)" usw.).
Das Problem verschwand von selbst, nachdem ich cocoapods mit dem Standardbefehl install/update auf die neueste Debugversion aktualisiert hatte:
gem install cocoapods --pre
oder:
Sudo gem install cocoapods --pre
(wenn Sudo während der Installation verwendet wurde).
Es muss ein Cocoapoden-Fehler gewesen sein.
Für mich war das iOS-Bereitstellungsziel für mein Pods-Projekt niedriger als mein Projekt. Nachdem ich es wie mein Projekt gemacht hatte, konnte ich die Header-Datei finden.
Dies war die Antwort für mich, ich habe die Kokosapods aktualisiert und ich denke, dass die PODS_HEADERS_SEARCH_PATHS verschwunden sind. Meine Lösung war ähnlich wie diese, aber ich verwendete "$ (PODS_ROOT)/Headers" - Andrew Aitken
Vielen Dank für diese Antwort. Es fiel mir schwer, nach Wegen zu suchen, um mein Problem zu beheben. Vielen Dank.