CoreData NSManagedSubClass files generating duplicate files? - xcode

I recently had to move my project to a different folder, and now when I run for some reason when I create the NSManagedSubclasses it seems to be making two copies. One in the correct location I tell it to save and another in Library->Developer->Xcode->DerivedData->WorkOrders-eamzgsjrwlhqoohhbyqilrvnbskh->Build->Intermediates->Workorders.build->Debug-iphoneos->WorkOrders.build->DerivedData->CoreDataGenereated->Workorders-> (NSSubclassed files here)
My problem is it won't compile now with the error below.
<unknown>:0: error: filename "Uploads+CoreDataClass.swift" used twice: '/Users/josephastrahan/Documents/Distribution.Tech/Work_Orders_iPhone/WorkOrders/Uploads+CoreDataClass.swift' and '/Users/josephastrahan/Library/Developer/Xcode/DerivedData/WorkOrders-eamzgsjrwlhqoohhbyqilrvnbskh/Build/Intermediates/WorkOrders.build/Debug-iphoneos/WorkOrders.build/DerivedSources/CoreDataGenerated/WorkOrders/Uploads+CoreDataClass.swift'
<unknown>:0: note: filenames are used to distinguish private declarations with the same name
<unknown>:0: error: filename "Uploads+CoreDataProperties.swift" used twice: '/Users/josephastrahan/Documents/Distribution.Tech/Work_Orders_iPhone/WorkOrders/Uploads+CoreDataProperties.swift' and '/Users/josephastrahan/Library/Developer/Xcode/DerivedData/WorkOrders-eamzgsjrwlhqoohhbyqilrvnbskh/Build/Intermediates/WorkOrders.build/Debug-iphoneos/WorkOrders.build/DerivedSources/CoreDataGenerated/WorkOrders/Uploads+CoreDataProperties.swift'
<unknown>:0: note: filenames are used to distinguish private declarations with the same name
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc failed with exit code 1
For some reason it thinks the same file is being declared twice, very bizarre and not sure how to fix this. I looked at other answers here (How to resolve error showing like filename used twice), but none of the answers solved my issue.
Note:: Also, If I delete the files they just come right back in the derivedData location you see in the attached image upon recompilation.
Even stranger, I was doing some tests, and I created only the workorder object but not the upload object and it compiles fine! I look in my build phases and don't see upload anywhere even though workorder has a relationship to it in code! It must be accessing the file from that derivedLocation for some reason.
Any help why is appreciated.

I think I found the solution but not sure why, so anyone that can elaborate would be appreciative.
I was reading a post here (XCode 8 generates broken NSManagedObject subclasses for iOS 10), and after reading the answer by Ryan H. I figured to give it a try.
By setting the codegen option to manual and setting the global space to my current project (see attached image), I deleted the files in the derived location and now they don't reappear and I don't get the duplicate error and everything compiles. I'm not sure how the codegen option even changed in the firstplace but something to watch out for sure.

Related

Changing Archive Type from *Generic Xcode Archive* to *Mac App Archive*

I've got a small command line app written in Swift, that I'd now like to archive. Like a number of others before me however, I've come up against the problem of how to change the Archive Type from Generic Xcode Archive to Mac App Archive.
The majority of previous answers addressing this problem suggest setting the Skips Install flag to No for the target. I've done this, but it made no difference. I've also tried setting the same flag to No for the project, but the result remains the same. Some of these answers also make a number of other suggestions, which I've also followed where appropriate, but still the Archive Type refuses to yield.
The entire project consists of a single 10-line file, and I've now run out of ideas about what else to fiddle about with.
The type is determined by the content of the archive. If you have a single .app in your /Products/Applications folder (inside the archive) this will qualify as a Application-Archive. If you have more files in that folder or if its not an .app, you've got a different type (like Generic Xcode Archive)

Introjucer/Visual Studio 2013 object file clashes

I've got two files in my build named State.cpp. When I generate the VS project with the Introjucer and try to compile, both of those files clash to the same object file and I get the warning:
Warning 1 warning MSB8027: Two or more files with the name of
State.cpp will produce outputs to the same location. This can lead to
an incorrect build result. The files involved are
......\audio\State.cpp, ......\sg\State.cpp.
and then various link errors.
I can correct this easily enough within VS by modifying the Object File Name property on the VS project. However, when I regenerate the project with the Introjucer, that setting gets blown away.
Is there a setting I can use in the Inrojucer's config pages to prevent the clashes?
Just to close this one down...
There isn't. Rename the file for now.
We discussed this on the forum. I think Jules is up for making a change to the Introjucer to fix this - but it hasn't been done yet.
http://www.juce.com/forum/topic/msvc-build-consistency
http://www.juce.com/forum/topic/introjucer/visual-studio-2013-object-file-clashes

Xcode: no such file or directory error

So I'm trying to adapt a file maker plugin to work on a Mac with xcode. There is code already written and compiled for the plugin but we need to update because a lot of internal changes have been made. I open the project in xcode and hit build and I'm given something like 135 errors saying that these files don't exist (e.g. "error: FMWrapper/FMXExtern.h: No such file or directory"). The issue is I'm looking at these files right now, they certainly exist, it's just that they aren't getting read. I've moved them through the project to nearly every file and I still get the same error. The lines that are causing the errors are as such:
#include "FMWrapper/FMXExtern.h"
And so on...
Any suggestions?
The compiler won't scan your whole hard disk for included files recursively (unless you ask it to -- but don't! :). You need to help it out. Otherwise, your builds would take ages.
One way is to specify the path to these sources using the Xcode build setting HEADER_SEARCH_PATHS or USER_HEADER_SEARCH_PATHS.
So you tell Xcode to add the directory that contains FMWrapper/ to the search paths.
Xcode Build Setting Reference

Disable warnings coming from a specific folder

I've set up an Xcode project where part of the code (a folder in this case) comes from a svn repository.
The folder is constantly updated by an external partner and it contains .h and .m files. In particular, these files are included in the project since set up as Header Search Paths and Library Search Paths within my Target.
Since, .h files contain a lot of warnings (I receive the Showing first 200 warning only message), Xcode does not allow me to show my code warnings.
Based on this scenario, how is it possible to prevent Xcode to show those warnings for that specific folder?
I followed few discussions within SO (Selectively disable GCC warnings for only part of a translation unit?, Turn off warnings coming from subprojects) but I haven't found a solution yet.
Thank you in advance.
Since I've found a solution I reply to my own question. Hope this can help other people.
A partial solution for the problem can be found here at How to disable new Xcode 4.6 warning for whole project ? “… used as the name of the previous parameter rather than as part of the selector". I upvoted!
Obviously, I'm waiting the vendor will fix the problem since this workaround disable such type of warnings for my own code. And I don't want such type of behavior.
Cheers.

Xcode 4 gcc failure on Archive build: skips precompile step?

I have been able to Archive on Xcode 4 successfully, but all of a sudden (??), I can't. The build fails with an invalid .pch file. The error is pasted in below (got from a reattempt with -Winvalid-pch, but what seems to be happening from the build log is that the precompiled header is not actually getting precompiled-- it's an iOS app, and goes straight from a CopyPNG step to a .m compile.
Could I have flipped something by accident? Nothing seems odd in my diff of the .pbxproj file.
cc1obj: warning: /Users/myname/Library/Developer/Xcode/DerivedData/Foo-afikuaovoaeqhreaaaakpafseuuv/Build/PrecompiledHeaders/Foo_Prefix-guqixmujoiaaaacwjctfkrztxmbz/Foo_Prefix.pch.gch: created by a different GCC executable
cc1obj: error: /Users/myname/Library/Developer/Xcode/DerivedData/Foo-afikuaovoaeqhreaaaakpafseuuv/Build/PrecompiledHeaders/Foo_Prefix-guqixmujoiaaaacwjctfkrztxmbz/Foo_Prefix.pch: No such file or directory
cc1obj: error: one or more PCH files were found, but they were invalid
The "Precompile Prefix Header" build setting is "Yes" for all configurations. Product->Clean doesn't help. Deleting the cached pch stuff under derived data doesn't fix it. Really seems like the whole "precompile" step is missing.
Another factoid: Enabling the setting "Increase Sharing of Precompiled Headers" DOES let it succeed. But I can find almost no reference to what this flag really does, and I have never used it before. And perhaps reasonably, the precompile step still doesn't show up when this happens.
Have you cleaned and then rebuilt? Product Menu ==> Clean. Cleaning usually solves such problems, effectively instructing Xcode to compile everything, regardless of whether it thinks the previous build of that file is still valid.
If that fails, try wiping out the Derived Data folder for the project, at ~/Library/Developer/Xcode/DerivedData/YourProjectNamexxx where xxx is a uuid-style string.
The approved answer is correct, just a note that it works only in some cases.
I just converted a project into workspace and changed Derived Data Location from default to Workspace-relative. Precompiled headers stopped working immediately and cleaning the old location didn't seem to make any difference. Well of cource, since it was the OLD location!
Workspace relative location seems to located inside folder, where the workspace file (myProject.xcworkspace) was saved. There's now new subfolder DerivedData, which contains folder named by workspace, which contains the familiar stuff.
Index folder contains the PrecompiledHeaders, which contains (finally) the several subfolders. Deleting all of those and recompiling forced precompiling happen.

Resources