Pods / Header leer nach Pod-Installation

Proble

Ich hatte in meinem Projekt (voll funktionsfähiges Projekt) bis zum letzten @ einen Funktionssatz von Podpod install run, jetzt erhalte ich "Datei nicht gefunden" -Fehler für die in meinem Bridging-Header genannten Header (dies ist ein Swift-Projekt mit Obj-C-Includes). Nach einigen Recherchen schien es Symlinks zu den Überschriften in @ zu gebePods/Headers, dieses Verzeichnis ist für mich leer. Die Pods selbst wurden jedoch heruntergeladen und alle entsprechendenPods/[Lib] Verzeichnisse existieren.

etzter bekannter guter Zusta

Was ich direkt vor dem Auftreten dieses Fehlers geändert habe, war die Angabe von:git und:commit Flags für eine der Bibliotheken, in die ich gezogen habe. Ich habe dannpod install und die Fehlermeldung "Datei nicht gefunden" wurde angezeigt. Zu der Zeit verwendete ich Cocoapods 0.39

Aktuellen Zustan

Ich habe ein paar Lösungen aus anderen Stapelüberlauf-Threads ausprobiert, einschließlich des Hinzufügens vonUser Header Search Paths, das keine Wirkung hatte (jetzt zurück zum Original), und meine Cocoapods aktualisieren. Meine aktuelle Version von Cocoapods ist jetzt 1.0.0.beta.6. Abgesehen von zusätzlichen Kopfschmerzen, die ich hatte, als ich Teile meines Podfiles neu schreiben musste, um den neuen Standards zu entsprechen, bin ich jetzt wieder in demselben Zustand (alle Bibliotheken wurden erfolgreich heruntergeladen, aber die Header wurden nicht gefunden).

Hier ist ein Beispiel, wie ich meine Header in den Bridging-Header einbinde:

// In this header, you should import all the public headers of your framework using statements like #import <MyKit/PublicHeader.h>
#import <CocoaLumberjack/CocoaLumberjack.h>

Und hier ist, wie mein Podfile aussieht (ich habe versucht, es zu verkleinern, um irrelevanten Inhalt zu vermeiden):

source 'https://github.com/CocoaPods/Specs'
platform :ios, '8.0'

use_frameworks!
pod 'CocoaLumberjack', '2.0.0'
pod 'SwiftyJSON', '~> 2.3'
pod 'Classy', :git => 'https://github.com/ClassyKit/Classy.git', :commit => 'c319908f8bded62e268dfd48ee5d65329b819129'

workspace 'my.work-ios'
project 'mywork' # sdk
project 'Examples/example1' # sample project using sdk
project 'my.work-ios.xcodeproj' # placeholder for main project, not really in use

target 'UnitTests' do
  pod 'Specta'
  pod 'Expecta'
  pod 'OCMock'
  pod 'OHHTTPStubs'
end

# Copy acknowledgements to the Settings.bundle
post_install do | installer |
  require 'fileutils'

  pods_acknowledgements_path = 'Pods/Target Support Files/Pods/Pods-Acknowledgements.plist'
  settings_bundle_path = Dir.glob("**/*Settings.bundle*").first

  if File.file?(pods_acknowledgements_path)
    puts 'Copying acknowledgements to Settings.bundle'
    FileUtils.cp_r(pods_acknowledgements_path, "#{settings_bundle_path}/Acknowledgements.plist", :remove_destination => true)
  end

  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings['OTHER_SWIFT_FLAGS'] = "-DLEGACY"
    end
  end
end
Aktualisiere

Nach einigem mehr Graben entdeckte ich, dass der Täter @ iuse_frameworks! Befehl, es wegzulassen (und im Gegenzug Swift-Bibliotheken zu entfernen, weil es für sie erforderlich ist) verursachtPods/Headers mit @ gefüllt werdPrivate undPublic -Verzeichnisse, zusammen mit Symlinks für die relevanten Header.

Das war in früheren Versionen von cocoapods nicht der Fall, und ich versuche immer noch zu verstehen, was passiert, da das Weglassen dieses Befehls für mich keine brauchbare Problemumgehung darstellt (angesichts der von mir in meiner App verwendeten Swift-Bibliotheken).

Update 2

Dies ist bereits in den Kommentaren erwähnt, aber der Einfachheit halber stelle ich dies auch hier. Dies scheint auf einen Fehler zurückzuführen zu sein, der in diesem Thread gemeldet wurde:https: //github.com/CocoaPods/CocoaPods/issues/4605#issuecomment-20882214. Der Thread schlägt auch einige Problemumgehungen vor, die für einige gut genug sein können. Für mich war das nicht der Fall, also bin ich auf 0,39 zurückgekehrt.

Antworten auf die Frage(2)

Ihre Antwort auf die Frage