Currently, my Xcode Projects are in ~/Desktop/Xcode Projects/
I'd like to move all projects to ~/Desktop/Xcode Projects/Training/
One of these directories contains Classes I've defined.
Can I move Xcode 6 projects from Finder/Terminal or from within Xcode?
I'm using defaults under Xcode 6.1 (Git repository, and "Relative to Group" files.
My StackOverflow searches show steps for Xcode 4. Is this cleaner in Xcode 6??
Any solution or pointer to docs would be appreciated!
Moving the projects from one location to other should not cause any issue.
Regarding the group files that you have linked in the project file you can just that file in the Mac and re-link the same. Mostly it should be just changing the versions number of Xcode.
Nor sure about your Git config though.
I want to warn about a few possible complications, though.
First, if you've set a Custom Working Directory (e.g. via the Scheme) that pointed to a folder that you're dragging, it won't automatically update to the new location.
Second, if you've linked to custom libraries or frameworks and the path was saved relative to your project folder (which is the default behavior in XCode) then the path to these may be broken.
Oh, and the local git stuff should be fine, since git uses relative paths.
Related
I have two developers working off the same codebase, I'm trying to have each dev have their own API keys both outside version control. The issue I'm running into is this:
Dev 1 adds a config file called configActual.plist, has configActual.plist on the .gitignore, commits and pushes.
Dev 2 clones the project and sees that the configActual.plist is red since xcode can find the file. Dev 2 can't just add the file because now XCode won't compile since it cannot find the original file. Even if Dev 2 forces their own file in and removes the old reference, this just adds a new record to the pbxproj, putting each dev forever out of sync.
Ultimately how do I hide a file from version control while still allowing XCode to find the local version which is outside version control?
I solved this by adding a specific version of the "missing" file through finder, then XCode recognized the new file under the old reference. It turns from red to black.
From the beginning of my project, I use a custom framework, let's call it "custom.framework". But there was a bug in this framework and now I want to use another version of the "custom.framework".
At first, I simply removed the "custom.framework" file from my project and added the new one. But nothing changed, the bug was still there.
After multiple tries and hours, I understood that Xcode add the old version in memory and used this one instead of the new version. I know it because in the new version I added a method and when I cmd+click the class I've add the method into, it's not there and the file's path is unavailable.
Searching through the web, I tried to change some version parameters to my framework projects: Compatibility version, Curent Library version, Framework version. But this didn't change anything to Xcode which keeps using the old version.
I also tried to make the framework's project as a sub-project and add resulting framework as a dependency to my target. It worked well, but as the framework's project is on a separated remote git repository, I don't think this is an acceptable solution.
So my last try was to build a "custom2.framework", to force Xcode to use the real file and not some cached version. But again, it doesn't work and when building I get errors telling me that all my classes in custom2.framework are duplicated symbols of its cached version of "custom.framework".
So my question is simple: how can I finally tell Xcode to deleted its cached old version and let me use the file I gave him? I already tried to delete my project's derivedData but it seems cached frameworks aren't there.... I'm so desperate :(
Edit: Here are 2 screenshots to illustrate the issue
First screenshot is the path as shown by Xcode when I opened the file from the .framework object in the project navigator.
Second screenshot is the path as shown by Xcode when I opened the file from a cmd+click to a "DCEquipmentManager" in code.
As you can see, the framework linked with the code is not the framework in the project.
it seems problem with binding in new framework, your project still linked with old framework files.
try to remove all files and folder related to your "custom.framework and also remove path for that framework from project setting--> build setting --> search Path
Then after Drag and Drop Your "custom.framework" files in project.
it works for me.hope it resolve your problem.
Please try to clear derrived data:
Window -> Organizer
at the right side you will see projects list. Find your project and tap on it. I the top part of window you will see button delete in front of Derrived data, tap on it.
I guess it will solve your problem.
It might sound silly, but sometimes restarting XCode or the whole machine fix things.
Did you remove the old framework from Build Phases --> Link Binary With Libraries?
Use Clean Build Folder: option-shift-command-K, or select it from the Product menu when holding down the alt/option key.
First lets say something upfront. The build stage is a(are) command line tool(s) that is managed by Xcode according to your Build Settings.
So when Xcode doesn't find your Framework - the Build System will usually also not find it. This forces you to act but may end up in confused Xcode to catch an older reference.
Yes it may happen that the Header Xcode is pointing to is correct but the build system still uses an old copy somewhere. An outdated copy can dangle around literally anywhere depending on the steps you took before.
It (Xcode) assumes where it is located but the Build System still uses another version or the Search Paths just pointing in the wrong Locations even if they are visible to you and even your Framework icons are visible in the lists. So when you erase the last build you actually only force Xcode to rebuild from the known arguments, the settings stay the same, the lists stay the same. Even restarting Xcode does not change anything, the problem persists.
Ergo: Compiler Instructions, Xcode settings and Build System settings don't match what the code tells with #import <NAME/Name.h>
So you will check at least those 6 stages again:
Is your Framework Header File published in your Framework project?
are Build Settings really pointing to the right Framework Search Paths or System Framework Search Paths?
Is your Framework in linking list?
Is your Framework in Embed Framework list?
Does your framework appear in the Framework Group Folder in Workspace/Project Browser? (usually the very last Group Folder in the Browser below all your other files)
Is my Folder Structure correct?
At least 1 to 4 must be right otherwise it will fail.
Here a random list of common causes
Framework is located outside your Source Paths structure
Structure got changed after you added it to the project
You use Workspace's where Framework development and Final Application can appear side by side but you assume Xcode uses this to change its Search Paths
The contained build settings are misleading from former drag and drop operations, ending up tricking Xcode in the "wrong" corner. In this case recreating a project is just one of the possible ways to fix it but not the solution.
Also dragging a Framework into your Project > General or separated in Build Phases > Link Binary list or Embed Framework lists does not make Xcode aware of the wrong Build Settings.
The Linking works, embedding works, but compiling does not. The Header information is still missing.
The solution must be to correct your Build Settings.
As mentioned above Build System and Xcode are two different things. In particular only setting the right Framework Search Paths will solve those issues, even if you managed to kick your derived data manually.
Erasing Derived data?
Derived data is the place where precompiler collects data to compile. So it can be seen as expression of what all the settings are told to do. Erasing it does of course not change the settings but may fix inconsistencies related to former Build Settings. It would erase the derived data and rebuild from the Build System Settings you gave.
Correcting Linking?
Also Linking is not the same as making Xcode aware of the desired Headers. Linking is for your final Product to know where Symbols are to call on them at runtime, it does not change Framework Search Paths and System Framework Search Paths, they stay the same as given.
But it is not wrong to start fixing first with
Product > Clean Build Folder, it forces your build to parse all and compile all again on the next Build.
When the troubles come up because of folder structure in parallel or Frameworks are simply placed outside the Source Directory then you must point to them directly or relative.
Most likely you should place one extra entry in your Framework Search Paths like $(SRCROOT)/../Yourframeworksource/build/Debug. expression to point to relative higher folder structure.
Needless to say that a Release Build likely needs another entry ending in "/Release".Hint: Well you can have different Search Paths for different Compile Schemes..
This works particular good after you cleaned Linking List, Embed Frameworks List and then also check the very last Group Folder "Frameworks" for double entries to drag and drop a fresh Framework reference in there.
How to know if leading /../ will fix it?
Click on the dropped Framework Icon inside the workspace Framework Group Folder (lower most) while your Project is the active selected to work on, now watch for the relative Path information on the very upper right side of Xcode, if there is some /../ you know you need it as well.
Sorting of Framework Search Paths
play a role of course, just the same as #import/#include rule sorting matters.
Remember the first found, first wins rule because often we use #import that works different then #include but ignores second attempts to declare. This leads to once wrongfully declared headers to hide corrected declarations later on in parsing that share the same filename or define rules
#ifndef xyz
#define xyz
// all your code here.
// a second read attempt would be ignored
// a second read is hidden also when you use #include then.
#endif
So you can sort those entries either by code and/or in the build settings if needed because of course it matters what is declared before other declarations depend on it.
I'm new to programming on iOS and I'm running into a roadblock with adding dependencies to my repository.
When I drag and drop a framework into the project directory and reference everything, I can build the project no problem. The issue is when I commit my project to the repository, the framework files do not get copied over. I can see that they are located in their original directory in some other location. Xcode merely references these files instead of adding them to the project directory.
So my question is, how do you add a framework or dependency to a project directory and commit it alongside your project to your repository?
Note I'm using SVN, however a Version Management System agnostic solution works for me.
In your case, or most cases people just download the framework and add it from there directly though it works in their machines, but will not work in other machine, because of absolute path added to the Header Search Paths settings in Build Settings.
In case of Third Party frameworks are as follows, will work for any case. Add the relative path rather than absolute path, though you don't set it, it is automatically added while you add a framework. So what are the steps? See below
Step 1
Create a folder named framework inside your svn/git folder of your project, and put all the frameworks inside the folder..
Step 2
Now add the framework, from the framework folder as you were doing earlier.
Step 3
Check your Header Search Paths in Build Settings. You will see entry for your framework header path. It should look something like
/Users/username/ProjectFolder/Project/frameworks/myframework/framework.h
Change the above entry by
$(SRCROOT)/frameworks/myframework/framework.h
Doing the above will automatically change this /Users/username/ProjectFolder/Project/ part of your path according to any system you clone the project. And it will work automatically.
Note - Before performing the steps, remove all old Header entries, which has absolute path.
Hope it helps.
Cheers.
I'm building an iOS app using unity3D. Everything goes ok until I try to build the solution. Unity builds the xCode project with 0 problems but then, when I try to build with xCode, I get several, all of them the same: "*.h not found".
The problem in this is that the headers don't exist in the project folder, but in the original-unity project folder they do exist.
I've seen a lot of similar problems around the web, but most of them relate to independent xCode projects, being the solution messing with the paths and so on... But with a project built by unity is it supposed to change that? When I go check them, they seem correct...
I've also seen that unity had a problem and by reinstalling it would fix the problem. Unfortunately it didn't...
Does anyone know what kind of problem is this? Should I change the build paths even though unity set them some way? Is it unity's fault?
Thank in advance
Native plugins need to be stored in special folder Plugins, for iOS it is Assets/Plugins/iOS. Citing from Unity - Building Plugins for iOS:
Automated plugin integration
Unity iOS supports automated plugin integration in a limited way. All files with extensions .a,.m,.mm,.c,.cpp located in the Assets/Plugins/iOS folder will be merged into the generated Xcode project automatically. However, merging is done by symlinking files from Assets/Plugins/iOS to the final destination, which might affect some workflows. The .h files are not included in the Xcode project tree, but they appear on the destination file system, thus allowing compilation of .m/.mm/.c/.cpp files.
Note: subfolders are currently not supported.
I marked the subfolders statement bold as I ran into trouble with this some time ago :)
There are bunch of helper filess in 'iPublicUtility' folder of several audio related Apple sample codes, such as aurioTouch:
http://developer.apple.com/library/ios/#samplecode/aurioTouch/Introduction/Intro.html
I can build these samples fine. But whenever I create a new project for testing and include the files from 'iPublicUtility' folder, I get:
'CADebugPrintf.h: no such file or directory ... ' error in 'CADebugMacros.h' file.
I made the settings of my test project to coincide with Apple samples, but this error is
not going away. Any suggestion?
SDK: iOS 4.2,
iMac OSX 10.6.6
Thanks all.
sy
select the Target, open the Build Settings pane, search for "Preprocessor Macros". Leave the fields blank (I've got rid of a DEBUG entry)
I used the answer provided by Justin and it worked fine, until I installed Xcode 4.3.1 and the problem came back.
Currently I solved this by downloading CADebugPrintf.h and .cpp.
I found the 2 files at this link:
http://svn.perian.org/trunk/CoreAudio/PublicUtility/
Cheers.
i have three distributions of Xcode installed.
the file exists in all three.
1) verify that the file exists on your system.
2a) add a search path to your project for the PublicUtility directory
or
2b) add the header to the target's "copy headers" build phase
depending on how many depends you have for these files, you may want a more reliable approach (which exists). one (fairly) safe/easy way to do this if you use a lot of the audio technologies and sources is to add its parent dir's parent dir to your search paths or source trees (recursively).
another way is to add it to a shared build settings file.
you could also copy a specific release someplace, then add that to your search paths. just be aware that the sources get updated somewhat regularly, so you'll have to update it when it's a good time for you. in this case, you'll should change your project references as well.
Edit: Adding the search path (2a)
One way to add a search path (assuming Xcode tools are installed at : /Developer/):
1) In Xcode (3), select the target.
2) cmd+i (get info)
3) select the "Build" tab of the info window
4) enter HEADER_SEARCH_PATHS into the search field
5) if the value is not defined at this level (e.g., it is not bold), then set the value to /Developer/Extras/CoreAudio/PublicUtility/ $(inherited)
if it is already defined at that level, then add /Developer/Extras/CoreAudio/PublicUtility/ to the list of directories to search (the value).
if you want to search the library recursively, use /Developer/Extras/CoreAudio/**. this may be useful when building AUs, or other projects which require the AU includes and PublicUtility includes.
Same problem, but seemed to have fixed it by downloading from the link below and adding in the missing CADebugPrintf.h and CADebugPrintf.cpp files.
https://developer.apple.com/library/ios/samplecode/CoreAudioUtilityClasses/Listings/CoreAudio_PublicUtility_CADebugPrintf_h.html
I was having the same problem and downloading the files into the iPublicUtility folder did not solve it. I found the answer by accident while learning about .mm extension files on this page:
Objective C Project using C++ POSIX Classes
I renamed my implementation file with a .mm and the compiler errors disappeared. Hope this may help someone down the line!