Posts

Post not yet marked as solved
5 Replies
Having the same problem, done all the "total clean of cocoa pods and derived data".In my case it only effects applications which uses the CSV.swift framework and it's only from that it complains.warning: Swift error in fallback scratch context: <module-includes>:1:9: note: in file included from <module-includes>:1:#import "Headers/CSV.swift-umbrella.h" ^error: /Users/totte/Documents/projects/Projects for Asset TV/GroupTime/GroupTime/Pods/Target Support Files/CSV.swift/CSV.swift-umbrella.h:2:9: error: 'Cocoa/Cocoa.h' file not found#import <Cocoa/Cocoa.h> ^/Users/totte/Documents/projects/Projects for Asset TV/GroupTime/GroupTime/Pods/Target Support Files/CSV.swift/CSV.swift-umbrella.h:2:9: note: did not find header 'Cocoa.h' in framework 'Cocoa' (loaded from '/System/Library/Frameworks')#import <Cocoa/Cocoa.h> ^error: could not build Objective-C module 'CSV'note: This error message is displayed only once. If the error displayed above is due to conflicting search paths to Clang modules in different images of the debugged executable, this can slow down debugging of Swift code significantly, since a fresh Swift context has to be created every time a conflict is encountered.Anyone has any more ideas? Do the framework needs changes?
Post not yet marked as solved
2 Replies
Hi Quinn,ticket files has been in my bucket of ideas, and as the apps are launched through the command master, ( can't guarantee though that the users wont add the to the dock ) it knows something is launched and I already have code to check if something is running (to handle "need to quit to update scenarios"), so this approach it is then.I can always add a check for running to the look and check state machine to see who is running and who is no longer running and the file is still there, and then I can grab the crashlog and zip it up and hurl it back to the DB repository for later dissection. I think I have a plan worked out.Thanks!/ Totte