Changing xcodebuild sdk

You can change the xcodebuild command line tools from xcode itself by selecting Preferences -> Locations. But what about the commandline?

First you can check the build version by:

xcodebuild -version 

You can also check the currently used path to xcode by:

xcode-select --print-path

To actually change the path you use xcode-select again:

xcode-select -switch <path to xcode>

To determine the list of installed SDKs:

xcodebuild -showsdks

Install CocoaPods tooling on El Capitan

Since CocoaPods is based on Ruby, I prefer to install the gems associated with Ruby as a local user installation instead of using the default system gem location (see where that is by using gem env).

That way I can delete the entire gem folder if something goes really wrong – and I don't interfere with the system Ruby gems at all.

In my .bash_profile I have but one line referring to .bashrc:

source ~/.bashrc

In my .bashrc I put these lines:

Now when I execute

gem install cocoapods

all gems and dependencies goes into my local .gem folder. sudo is no longer needed to install CocoaPods.

The second valuable tool needed is the excellent CocoaPods plugin deintegrate. With deintegrate I can quickly remove a pod installation completely from a XCode project. Use it if something goes wrong. Install it by entering:

gem install cocoapods-deintegrate

Again the gem goes into the local .gem folder.

Open the pod bay doors, HAL

Below is a short list of very common Cocoapod errors and what to do in Xcode, if you should encounter them.

The target overrides your stuff

After doing a pod install this might happen:

[!] The target overrides the OTHER_CFLAGS build setting defined in .xcconfig. This can lead to problems with the CocoaPods installation
[!] The target overrides the OTHER_LDFLAGS build setting defined in .xcconfig. This can lead to problems with the CocoaPods installation
[!] The target overrides the GCC_PREPROCESSOR_DEFINITIONS build setting defined in`.xcconfig. This can lead to problems with the CocoaPods installation
[!] The target overrides the HEADER_SEARCH_PATHS build setting defined in`.xcconfig. This can lead to problems with the CocoaPods installation

These are common errors in legacy projects. The helpful error message hint that you should "Use the $(inherited)flag, or remove the build settings from the target". But how? We're going to use option number one.

First select the project in Project Navigator to show your PROJECT and your TARGETS. Second select the PROJECT and select Build Settings and All. Now you have to change the setup in a few places (provided you're seeing all four errors):

  • In Linking select Other Linker flags and add "$(inherited)".
  • In Search Paths select _Header Search Paths and add "$(inherited)".
  • In Apple LLVM 7.0 – Preprocessing select Preprocessor Macros and add "$(inherited)".
  • In Apple LLVM 7.0 – Custom Compiler Flags select Other C Flags and add "$(inherited)".

If you have any custom configuration settings then you have to add $(inherited) to each one.

Go through the same steps for each of your targets. Only add additional configuration settings in a target where they are needed. The targets should now inherit the settings from the project – along with COCOAPODS=1.

Run pod update again.

Undefined symbols for architecture

Your build fails with something that looks like this:

Undefined symbols for architecture x86_64:
  "_OBJC_CLASS$_YourClassName", referenced from:

Some answers will have you changing the architecture setting in your project target. That may be correct in your case. But it was not the answer in my case though. The answer was something much less obvious (it took me some days to find).

I was missing some needed frameworks in my project target. Frameworks that was included in the project but not in the project target. Once included the error went away. Thank you stackoverflow.

Another unrelated and tricky issue can give you the same error. The error happens when running test targets created by Cocoapods. Notice the class being referenced. That same class might not have been added properly to the group, where it belongs. Do that, pod update – and the error goes away.

ghc 7.10.1 and cabal-install 1.22 on Debian Jessie

I struggled quite a bit with installing ghc 7.10.1 and cabal 1.22 on Debian Jessie, so I’m taking serious notes this time. I read a lot of blogs and different todos – some of them involving Ubuntu repos – but this was the combination of things that actually worked.

First some preparations:

sudo apt-get install ghc
sudo apt-get install cabal-install

This will get you ghc 7.6.3 and cabal-install 1.20 – and you’ll need *ghc* to build *ghc*. Then on with some downloading and building of what you really want:

tar -xJvf ghc-7.10.1-x86_64-unknown-linux-deb7.tar.xz 
cd ghc-7.10.1/
make install

Note that CheckInstall doesn’t seem to work in this case. That would have been nice…

To upgrade cabal and cabal-install I did this:

sudo apt-get install zlib1g-dev
cabal install cabal cabal-install --global

Now you should have the latest and greatest ghc in /usr/local/bin – as well as cabal.

Useful git commands

Presenting my collection of useful git commands. Just so that I can remember them all when I need to.


When text=auto normalization is enabled in an existing repository, any text files containing CRLFs should be normalized. If they are not they will be normalized the next time someone tries to change them, causing unfortunate misattribution. Read more about this here.

So from a clean working directory:

echo "* text=auto" >>.gitattributes
rm .git/index     # Remove the index to force git to
git reset         # re-scan the working directory
git status        # Show files that will be normalized
git add -u
git add .gitattributes
git commit -m "Introduce end-of-line normalization"

Revert to a previous commit

This command is a nice one, if the present build is broken (for some reason) – and you need to quickly revert to a build you know works (while someone else figures out the reason why the present build is broken).

git reset --hard 62fbb3

Revert a file

You’ve written something in a file and now you wish to regret and revert that change entirely.

git checkout -- filename

Cherry-picking code

You’ve written code in commit 62fbb3 in the feature branch. It may contain a bug fix or code that other people need to have access to. Whatever the reason, you want to commit 62fbb3 in the master branch – but not all the other code you’ve written in the feature branch. So you cherry-pick the commit.

git checkout master
git cherry-pick 62fbb3

62fbb3 is now added and commited as a new commit in the master branch.


git log branch1..branch2 --no-merges

Show the commits in branch2 but not in branch1. Very useful if you’re comparing branches. The no-merges flag is only necessary if you want to exclude merges.


Recover a file that was accidentally deleted:

git checkout HEAD^ filename

This works if you know the exact name of the file.


git config --global myusername
git config --global myemail
git config --global push.default simple
git config --global core.autocrlf true

I find that push.default simple is better than push.default matching. Matching could lead to certain doom. Also this is an excellent link to understand autocrlf.

To list all of your settings:

git config --list


You’ll find yourself needing to stash code in a drawer sometimes:

git stash

You can list the contents of the drawer:

git stash list

To return to the stashed code, apply it:

git stash apply --index stash@2

The index parameter is to also restage any staged files.

The stash stays on until you remove it:

git stash drop stash@2


Create a local feature branch of master (and switch to it at the same time):

git checkout -b feature master

Tracking is the default behavior when the start point is a remote-tracking branch[1]. So there’s no need to include the –track option, if that is what you want. BTW the above command is shorthand for:

git branch feature
git checkout feature

Push the feature branch to the remote repository:

git push -u origin feature

Delete a local feature branch:

git branch -d feature

Push the deleted feature branch to the remote repository:

git push origin :feature


Create a local tag:

git tag 3.00.01

Push the tag to the remote repository:

git push --tags

Delete a local tag:

git tag -d 3.00.01

Push the deleted tag to the remote repository:

git push --delete origin 3.00.01

Pulling and fetching

Pull to get all the changes from the remote branch and merge them (if possible) into your local branch at the same time.

git pull

Fetch to get the changes from the remote branch to your local repository without doing the merge with your local branch as well.

git fetch

Then do a diff to see what the fetched changes are:

git diff origin/master

Then do a merge to actually merge the changes with your local branch.

git merge origin/master

More documentation at

Minified .js error in Eclipse

My Luna Eclipse doesn’t like minified .js files much. I see plenty of errors like “Syntax error on token ‘Invalid Regular Expression Options’, no accurate correction available” and “The left-hand side of an assignment must be a variable”.

I found the bugreport on this issue – and it seems that only patches exists so far. A final version of Eclipse with the patch implemented isn’t here quite yet.

So I’ve disabled my javascript validator like so (not a solution for everyone):

  • Right click your project
  • Select Properties -> Builders
  • Uncheck the “JavaScript Validator”

For it to take effect right click your project and select Validate. The error should now disappear.