GCC 5.2 in XCode 7.3 under OS-X 10.11

You may not need command line tools.

For sake, you can download the command line tools via XCode > OpenDeveloper Tool > More developer tools. But, although sources suggest that this can help with installing GCC, in my experience it is unclear whether that actually works.

You probably need an XCode plugin

There are two plugins at hmazhar/xcode-gcc on Github. I choose the 5.2 plugin and copy to the designated location.

You want GCC 5.2

I used to install GCC via home-brew, which provides the perfect excuse to go for a two hours walk in the park. But you know what? At the time of writing (April 2016) this doesn't work anymore.

Note: the following steps are likely to erase/override any previous GCC install.

• Used a tarball 
• ditto to copy the tarball to usr/local (DO NOT copy via Finder as it will trash your /usr folder - Probably an obscure terminal command would have saved me the hassle, eh)
• Renamed gcc to gcc-5 as  hinted by XCode's response to the build command.

Config for C++11

• Under Other C++ Flags you may need to add a flag for C++ 11 support.

Compile Code Online.

What if you wanted to quickly compile a little bit of C++ or Java? Yes, there are online services for that, for example:

• TutorialsPoint's CodingGround
• Ideone

Where this should get handy is producing online samples that are proven to work, or sometimes (for educational purposes) not work. What I was really after was an online tool that would cross compile my code on GCC, VS and Clang. Haven't found this yet.

If you're looking for a quick scratchpad, CodingGround works well. Saving and sharing projects? No luck.

Share Assets between Unity projects on OS-X

Unity's packaging system doesn't help much with keeping copies of the same assets in sync across projects. Over time this becomes a productivity killer which encourages copy-pasting assets everywhere. Fortunately, OS-X and Windows both allow using low level shared folders.

This article deals with sharing assets on OS-X to use across Unity projects. Using this stratagem, we make up for Unity's shocking lack of a class path, what were they even thinking.

First create a new git repository. Then, add the files that you want to share. Don't put unity projects in there, only assets.

We now share this to a Unity Assets folder using a symlink. A symlink is not an alias. Use Terminal to define a symlink, like this:

ln -s path/to/original path/to/Assets/name_of_original

where:

• path/to/original is the root folder for your shared assets.
• path/to/Assets/name_of_original is the 'alias' giving access to shared files.

Repeat the same for all projects where you want to share this. This can be tedious; fortunately there is a trick: although a symlink is not an alias, symlinks can be duplicated and renamed in the Finder!

What happens in Unity?

Unity will display a warning when detecting the sym-linked folder. It's telling us that issues may arise if projects using inconsistent Unity versions use the same asset.
Better than not being able to use them at all.

How does version control view a symlink?

Both Git and Mercurial view our symlinked-folder as a file that can be either ignored or checked in. I opted for checking the files in (because Unity creates meta for these and meta are, for the better and especially for the worse, the wet dirt that holds Unity projects together.

Overall this works pretty much as we want it to - we're managing shared assets separately from the project we are linking from.