Access Keys:
Skip to content (Access Key - 0)

Kobold2D™ Documentation

The All-In-One, Ready-To-Go development solution for cocos2d-iphone developers. Open source, ARC enabled, for iOS & Mac OS.

Switch to: Japanese Documentation

Level Up!

The Learn Cocos2D Book

Line-Drawing Game Starterkit

Excellent template code for creating your own Line-Drawing game, similar to popular titles such as Flight Control, Harbor Master, and Pirate Bay.

The iPhone RPG Engine

Rapidly create your own RPG or action-adventure game with this complete starter kit. Includes an ebook, game source code and a royalty-free art package.

Are you wondering why this page opened?
This page may be opened automatically during a Kobold2D build. Kobold2D does so because it determined that your Xcode Build Location setting is set to Locations Specified by Targets (in Xcode 4.3 called Legacy). Please read the entire page because it contains crucial information for you to build Kobold2D successfully.

Kobold2D does not build out of the box if your Xcode Build Location setting is set to Locations Specified by Targets (Xcode 4.3: Legacy) as indicated by this Xcode Build Error:

This article describes the quick fix and the recommended solution. It also explains the reasons why the recommended solution isn't recommended for nothing, and why the Locations Specified by Targets (Xcode 4.3: Legacy) setting should only be used if you are — for whatever reason — required to use it.

The Quick Fix (read the caveats!)

open the Common-All.xcconfig file:

remove the // comment from the //SYMROOT = .. line:

You do not have to use the default ~/Kobold2D/build location, you can use any other folder location. However you should not use the location or a subfolder of a Kobold2D installation or any Xcode project.
Quick Fix Caveats
You must issue a Product -> Clean every time you switch to a project using a different Kobold2D version than the version that was most recently built. Otherwise you may experience linker errors (undefined symbol) or worse, inexplicable crashes. This is why the quick fix is not recommended for continued use.

The Recommended Fix

Unless you are explicitly required (as per instructions of a specific library, or as per requirement from your employer) simply do not use the Locations Specified by Targets (Xcode 4.3: Legacy) setting.

Instead, change it back to the recommended setting Derived Data Location (Recommended) (Xcode 4.3: Unique or any other setting other than Legacy). You can make this change in Xcode -> Preferences -> Locations -> Advanced.

Xcode 4.0 through 4.2 Xcode 4.3 and newer

Why is "Derived Data Location" / "Unique" recommended?

Xcode 4 introduced the "Derived Data" location to solve long-standing issues of stale code and cleaning builds affecting other projects.

By using the default Build Location setting Derived Data Location (Recommended) (Xcode 4.3: Unique) Xcode 4 avoids prevalent issues present in Xcode 3, specifically when linking with static libraries:

Xcode is guaranteed to link with the correct static library, as each library is placed in a derived data folder unique to each project.

In Xcode 3 respectively Xcode 4 with Locations Specified by Targets (Xcode 4.3: Legacy) the library is placed in a common folder which may not be updated when the library changes, or when another project uses a different version of the library. This can lead to linker errors (undefined symbol) or worse, it can cause inexplicable runtime crashes. This problem is almost certainly going to surface once you start working with multiple versions of Kobold2D (ie after upgrading).

This is the main reason why Derived Data Location (Recommended) (Xcode 4.3: Unique) is the recommended setting not just for Kobold2D but for any Xcode project.

When issuing a Product -> Clean, only the current build configuration for the current project is cleaned.

In Xcode 3 respectively Xcode 4 with Locations Specified by Targets (Xcode 4.3: Legacy), all build configurations are cleaned and all projects linking to the same libraries are affected by the clean as well. In effect more code than necessary will have to be compiled again. This is simply a waste of your time.

Xcode 4 can still clean all of your projects. By selecting Product -> Clean while holding down the option key the menu item changes to Clean Build Folder… which will delete all your project's build output files.
Separating the "build" output folder from the project folder means it can not be accidentally added to source control.

Having build output files in source control can have dire consequences, such as: wasted space, bloated change history, permission issues, build files out of synch after source control operations, utterly confused Xcode.

Unless instructed otherwise, use "Derived Data Location (Recommended)" / "Unique"
The above issues should explain why Xcode itself labels the Derived Data / Unique option as (Recommended). You should use the recommended setting unless you are absolutely, irrevocably required to use Locations Specified by Targets (Xcode 4.3: Legacy).

I don't like the convoluted DerivedData path …

The majority of developers using Locations Specified by Targets (Xcode 4.3: Legacy) do so merely because they dislike the convoluted path to the DerivedData folder and/or because that's where Xcode 3 used to place build output files. This should never be a good enough reason to use this setting.

1) You can use the Custom or Relative setting for the Derived Data location to make the folder easier to find without negatively affecting builds.

2) You can quickly open the Derived Data folder through Window -> Organizer by selecting the desired project, then click the arrow symbol to the right of the Derived Data path to open the folder in a Finder window.

I must use the "Locations Specified by Targets" setting …

If there's a specific reason to use Locations Specified by Targets (Xcode 4.3: Legacy), usually a requirement of a (outdated?) library or a (uninformed?) employer, then you can only do one of these things:

1) Change the setting back and forth depending on the project you're working on. You can change the corresponding setting IDEBuildProductsLocationDeterminedByTargets directly in ~/Library/Preferences/

The setting can be changed while Xcode is running, so you may want to consider writing a script. You may want to try adding this script as a Run Script build phase to each project, it may or may not take effect for the current build but it will be in effect if you build a second time.

2) Bite the bullet, uncomment the SYMROOT line as instructed above and keep the caveats in mind. If you get linker errors or inexplicable crashes after switching, renaming or relocating projects, get into the habit of cleaning the build and try again before attempting anything else.

3) If you don't need the source code of the library that requires the Locations Specified by Targets (Xcode 4.3: Legacy) setting, you can build it once and then just link with the binary file that you placed to a common location on your hard drive.

4) Assuming the library in question is still being maintained, petition to update the library so that it supports proper Xcode 4 build locations. Or, if possible, spend some time to come up with the fix yourself.

5) Ask your employer what the rationale is for using Locations Specified by Targets (Xcode 4.3: Legacy). This may simply be an old habit, and as you may know, those die hardest. Maybe you can convince your boss that this setting is counterproductive and a potential waste of precious developer time.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
Adaptavist Theme Builder Powered by Atlassian Confluence