Kompilieren, Erstellen oder Archivieren von Problemen mit Xcode 4 (und Abhängigkeiten)


96

Diese Frage hat sich in den letzten Wochen weiterentwickelt, um allgemeinere Fragen zu behandeln (und Upgrades von älteren Projekten s).

Viele der Probleme können jedoch durch Befolgen derselben Anweisungen gelöst werden.

Wenn Sie eines der folgenden Probleme haben, probieren Sie die Methoden in der akzeptierten Antwort aus:

  • Xcode 4 kann eine App nicht archivieren
  • Xcode 4 erstellt ein unbrauchbares Archiv
  • Xcode 4 erstellt keine .ipa
  • Xcode 4 kann aufgrund von Präprozessorfehlern nicht kompiliert werden
  • Xcode 4 kann keine Header finden
  • Der vollständige Code von Xcode 4 funktioniert nicht
  • Projektabhängigkeiten werden nicht kompiliert
  • Das Hinzufügen einer Abhängigkeit verursacht eines der oben genannten Probleme

Ursprüngliche Frage

Titel: "Lexikon- oder Präprozessor-Problemdatei nicht gefunden" in Xcode 4

Ich habe ein Projekt in Xcode 4, das gut funktioniert und auf dem Gerät und dem Simulator ausgeführt wird, aber beim Versuch, es zu archivieren, treten Fehler auf, wenn nach Header-Dateien gesucht wird, die einer statischen Bibliothek zugeordnet sind:

In file included from /Volumes/Development/Path/LBProject/LBProject/LBProject-Prefix.pch:15:
In file included from /Volumes/Development/Path/LBProject/LBFDefines.h:23:
In file included from /Volumes/Development/Path/LBProject/Classes/LBProjectAppDelegate.h:11:
In file included from /Volumes/Development/Path/LBProject/LBProject/../FKNDirectory/FKNDirectoryManager.h:10:
/Volumes/Development/Path/LBProject/LBProject/../FKNDirectory/FKNDataModel.h:11:9: fatal error: 'Merchant.h' file not found [1]
 #import "Merchant.h"
         ^
1 error generated. 

Xcode gibt den Fehler aus

lexical or preprocessor issue file not found 

Viel Googeln hat gezeigt, dass viele Menschen dieses Problem haben, aber keine Lösung. Jeder hat eine Lösung oder sogar eine Ahnung.

Update: Die user headerSuchpfade sind ${BUILT_PRODUCTS_DIR}in allen Konfigurationen eingestellt. Es funktioniert mit jeder Konfiguration, außer bei der Archivierung.

Update 2: Merchant.h ist eine Core Data-Klasse, die automatisch generiert wird und sich daher im .xcdatamodeldPaket befindet. Die Header werden jedoch alle beim Erstellen der Bibliothek in das öffentliche Header-Verzeichnis kopiert.

Antworten:


119

NB: Die folgenden Schritte lösen 90% Ihrer Xcode-Archivprobleme. Aus den Kommentaren geht jedoch hervor, dass Sie versuchen, Xcode zuerst zu beenden . Dies kann Ihnen Stunden beim Einstellen von Optimierungen ersparen.

  1. Überprüfen Sie, ob die "Benutzer-Header-Pfade" korrekt sind (fügen Sie "" zu Pfaden für Leerzeichen hinzu, sowohl in Ihrem Projekt als auch in Abhängigkeiten).
  2. Setzen Sie "Immer nach Benutzerpfaden suchen" auf JA
  3. Erstellen Sie einen Gruppenaufruf "Indizieren von Headern" in Ihrem Projekt und ziehen Sie die Header in diese Gruppe. Fügen Sie KEINE Ziele hinzu, wenn Sie dazu aufgefordert werden. Dies schließt alle Header in Ihrem .xcdatamodeld ein . Sie müssen mit der rechten Maustaste klicken und den Paketinhalt anzeigen, um sie zu finden.
  4. Setzen Sie für alle Abhängigkeiten die Build-Einstellung " Installation überspringen" auf "Ja".
  5. Verschieben von "öffentlichen" Headern in Build-Phasen in "Projekt"
  6. Setzen Sie die Build-Einstellung "Installationsverzeichnis" auf Ihrem Ziel auf$(LOCAL_APPS_DIR)
  7. Ändern Sie die Ziel-Build-Einstellung "Alle Quelldateien nach Includes durchsuchen" in YES. ( Link )
  8. Bei neueren Versionen von Xcode (> 4.2) möchten Sie möglicherweise diese Frage zu Arbeitsbereichen lesen .
  9. Löschen Sie die Dateien project.xcworkspace manuell aus allen Projekten, auf die verwiesen wird

28
Der allerletzte Vorschlag ist alles, was ich brauche, um dieses Problem zu beheben. Xcode schließen und erneut öffnen.
Chris Miles

1
Ja, das gleiche für mich, musste nur Xcode neu starten. Dies geschah, nachdem ich Dateien im Projekt umbenannt und verschoben hatte.
Maurizio

Ich auch. Nichts ist frustrierender als ein Fehler, der nicht existieren sollte. Schön, dass es so einfach gelöst werden kann.
Maxedison

3
Hinweis für Three20-Benutzer, die alte Projekte von xcode3 auf xcode4 migrieren: Möglicherweise müssen Sie die xcode-Einstellungen / Standorte / Erweitert / -> vom Ziel angegebene Standorte ändern. Siehe stackoverflow.com/questions/5261447/... für mehr
Ben G

1
Heiliger Mist auf Nummer 1. Die Zitate! Die Umgebung $ (SRC_ROOT) kann natürlich mit einem Pfad mit Leerzeichen "aufgelöst" werden. Konnte nicht herausfinden, warum das Zippen meines Projekts und das Extrahieren an anderer Stelle zu einem Build-Fehler führte!
Erik Kerber

13

Ich hatte das gleiche Problem in XCode 4: "Lexikalisches oder Präprozessor-Problem MyFile.h nicht gefunden". MyFile.m war jedoch keine statische Bibliothek, sondern nur eine Standardklasse. Und MyFile.m und MyFile.h wurden ordnungsgemäß aufgenommen und im Projekt indiziert.

Also ... Ich habe XCode und den Simulator beendet, sie dann neu gestartet und das Problem ist verschwunden.


Ich hatte eine ähnliche Situation, aber der unerwünschte Fehler wurde angezeigt, weil eine nicht verwandte Eigenschaft, die zur selben Klasse gehörte, falsch referenziert wurde (im Grunde habe ich vergessen, self zu verwenden) - eine seltsame.
JARC

11

Ich stellte fest, dass das Problem behoben war, als ich die Ziel-Build-Einstellung "Alle Quelldateien nach Includes durchsuchen" von "Nein" in "Ja" änderte.


6

Ich konnte dieses Problem beheben, ohne Änderungen an den Build-Einstellungen vorzunehmen, indem ich einfach die .h-Dateien in das Projektverzeichnis im Finder kopierte. Ich habe sie NICHT zum Projekt hinzugefügt. Nur sie im Dateisystemverzeichnis des Projekts zu haben, schien ausreichend zu sein, damit die implizite Verknüpfung von Xcode ordnungsgemäß funktioniert. Weitere Details hier .


+1 Ich habe einen Link zu der Frage hinzugefügt, in der er die Antwort akzeptiert hat, danke für die Info!
Richard Stelling

4

Ich hatte so ein komisches Problem. Das Ändern von "Alle Ressourcendateien scannen ..." in "Ja" hat nicht geholfen. Ich habe mir die Framework-Suchpfade angesehen und festgestellt, dass dies der Fall war

  • $ (geerbt)
  • "$ (SRCROOT)"
  • "$ (SRCROOT) / mein / korrekter / Pfad"

Es schien richtig zu sein, scheiterte aber immer noch. Ich habe dann versucht, die Reihenfolge 2 & 3 neu zu ordnen, und plötzlich hat es gut funktioniert. Ich bin mir also nicht sicher, warum das so schlimm war, wollte es aber zur Liste der Dinge hinzufügen, die ich ausprobieren sollte, falls es jemand anderem hilft.


4

Meine Lösung bestand darin, meine zu ändern

#import "HeaderFile.h"

zu

#import <FrameworkName/HeaderFile.h>

und alles fing wieder an zu arbeiten. Was ungewöhnlich war, war, dass es nach einigen Bauarbeiten plötzlich nicht mehr funktionierte.


Ich habe alles andere mit meinem Teilprojekt versucht und dies war das einzige, was funktionieren würde. Danke dir.
Dirkoneill

Sie sollten weiterhin doppelte Anführungszeichen für statische Bibliotheken verwenden. Winkelklammern durchsuchen die Systemheaderpfade und durchsuchen keine Benutzerheaderpfade, es sei denn, Sie aktivieren auch die Option Immer Benutzerpfade suchen , die Sie nicht sollten, wenn Sie dies nicht benötigen.
Devios1

2

Das Problem hat sich beim Einstellen von selbst gelöst

Build-Einstellungen-> Projekt-> Suchpfade zu Ja


2

Ich hatte das gleiche - 2 Ziele in meinem Projekt ( Project und ProjectTest of GHUnit). Als mein Schema für Project eingerichtet wurde , war der Import von " <GHUnitIOS/GHUnit.h>Problem der lexikalischen oder Präprozessor- Problemdatei nicht gefunden" . Aber als ich ProjectTest als Schema festlegte , war alles in Ordnung. Also habe ich auch GHUnitIOS.frameworkin Project hinzugefügt .


Ich hatte das gegenteilige Problem. Siehe meine Antwort: stackoverflow.com/a/16783389/629014
slcott

1

Anscheinend sind Ihre Header-Suchpfade falsch und in Ihren Build-Einstellungen für das aktive Schema nicht richtig konfiguriert. Überprüfen Sie sie und aktualisieren Sie Ihre Frage mit der aktuellen Einstellung.


1

Ich habe ähnliche Probleme mit dem Simulator, aber nicht mit dem Gerät. Die Felder für den Header-Suchpfad sind leer (scheint Standard zu sein). Das Ändern von Arbeitsbereichen scheint das Problem jedoch gelöst zu haben. Vielleicht können Sie versuchen, einen neuen Arbeitsbereich zu erstellen, Ihr Projekt hinzufügen und prüfen, ob dies hilfreich ist. Jetzt untersuche ich warum.


1

Ich habe den Fehler "Datei nicht gefunden" für eine bestimmte .h-Datei in meinem Projekt erhalten. Ich habe das Problem behoben, indem ich diese .h-Datei aus dem Projekt entfernt ("Referenzen entfernen" ausgewählt) und erneut hinzugefügt habe.


1

Hinzufügen einer weiteren Variante: Ich hatte zwei Instanzen foo.min der Compile SourceErstellungsphase, für die zum Teil "Header nicht gefunden" verursacht wurde foo.h.


1

Noch eine Chance:

Im Arbeitsbereichsprojekt: Achten Sie im Abschnitt Ziel auf Phasen erstellen. Wie in vielen Handbüchern angegeben, benötigen Sie eine Erstellungsphase zum Kopieren von Dateien, um alle Ihre Header an einen anderen Ort zu kopieren, da iOS Framework keine Header-Dateien enthalten kann, die freigegeben werden sollen (dies ist mein Fall).

Wählen Sie für diese Dateien als Zieloption die Option "Produktverzeichnis". Oder ein anderes Verzeichnis von Ihnen, in dem sich die Header befinden.

Das hat bei mir funktioniert. Wahrscheinlich unterscheidet sich der Build für das Archiv- (oder Release-) Verzeichnis stark von dem für Build für Debug erwarteten.

Überprüfen Sie auch in Ihren Arbeitsbereichseinstellungen Ihr Build-Verzeichnis.

XD


0

Bei mir trat dieses Problem auf, nachdem ich dem Projekt neue Dateien hinzugefügt hatte. ein leeres .m und .h abgeleitet von NSObject. So habe ich es gelöst:

  1. XCode geschlossen und neu gestartet
  2. Löschte die beiden neuen Dateien über XCode
  3. Erfolgreich neu kompiliert

Ich habe sie danach wieder hinzugefügt und es hat auch funktioniert.

Auf jeden Fall ein Fehler in xCode ...

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.