Skip to content

Xcode for macOS

Why an alternative solution?

CLion works fine on macOS. However, there are some disadvantages:

  • CLion is not free in all conditions.

    CLion is free for students and teachers, as well as for open source projects. Xcode is free for all users and all projects.

  • CLion is slow

    Compiling with CMake is significantly slower than compiling with Xcode, even when both are set to use clang as the compiler.

    If CLion is set to use gcc/g++, the performance difference is much bigger and the error messages are much less helpful.

Xcode

Xcode is Apple's integrated development environment (IDE) for macOS and is the most common tool that is used to develop Mac applications.

Warning

Xcode and CGAL work great together as long as you don’t use the Xcode projects generated by CMake and instead create your own.

First, start by creating a new project (File > New > Project, or select "Create a new Xcode project" from the welcome window). Depending on what you plan to do, it can be any kind of project, but for simple things a 'Command Line Tool' works, which is found in the macOS tab under 'Application'. If you want something with a native Mac GUI, you probably should go for an App.

Once you’ve given your project a name, make sure that the language is set to C++ and click Next. Then decide where to save it, select if you want to create a local Git repository for it and you’re done. You’re then confronted with the main Xcode window.

In short, Xcode works on the basis of projects and targets, just like CLion with CMake. Without going into much detail, the project contains all your stuff and a target has the aim to create a given executable (or library, plug-in, etc.) based on some of the files in the project. A project can have many targets, like a codebase that produces two applications (eg macOS and iOS). Some of the settings at the project level cascade down to its targets, but I would recommend you to modify things directly at the target level.

So after you select the project (blueprint icon with three sticks that look like an A), select the target (black Terminal-looking icon). There, on the Build Settings tab, you will find a lot of options in several categories. Select the All and Combined tabs.

Many of these options don’t matter too much, but a few can thoroughly mess with your target, so unless you know what something means, leave the options with their defaults. However, there are a few that you will likely need to modify:

  • Search Paths > Framework Search Paths: If you’ve installed some dynamic libraries in the form of Mac Frameworks (rather than Mach-O .dylibs, you might want to add /Library/Frameworks here.
  • Search Paths > Header Search Paths: In most cases, you should add /opt/homebrew/include (Apple Silicon) or /usr/local/include (Intel) here.
  • Search Paths > Library Search Paths: In most cases, you should add /opt/homebrew/lib (Apple Silicon) or /usr/local/lib (Intel) here.
  • Apple Clang - Code Generation > Optimization Level > Debug: If you're having performance issues with CGAL, you can increase the optimisation level here to -O1 or -O2 here. However, this will cause make the Xcode debugger less useful.
  • Apple Clang - Language > C Language Dialect: For better cross-platform code, you should select c11 rather than gnu11 here.
  • Apple Clang - Language - C++ > C++ Language Dialect: Here you should really choose wisely depending on your code and the packages that you're using. The safest bet for old code is probably GNU++98, but many new-ish packages will only work with C++11, C++14, or even C++17 (or the GNU variants). In order to future-proof your code, you should probably select C++17 or even C++20 as much as possible. I personally think it’s nicer to avoid the GCC compliant GNU++ varieties, since these might have issues with other compilers.

Next, go to the Build Phases tab of the same target. Here, you should add all the dynamic libraries that your code will need to link to. So, open the Link Binary With Libraries collapsible menu and click the "+" sign below.

You’ll get a cascading sheet containing all the standard macOS X Frameworks as contained in /System/Library/Frameworks. You’ll also get all the dynamic libraries contained in /usr/lib. However, CGAL and its dependencies will not be there.

So, instead click on the Add Other... dropdown and Add Files..., after which you’ll get a standard Finder Open window. Since the libraries you installed are in /usr/local/lib by default and that directory is by default hidden, just type shift+command+g (⇧⌘G) to Go to a folder and type /usr/local/lib. There’s autocomplete.

In there, you should select all the libraries that your CGAL packages need. Repeat this process a few times or select all the ones you need at the same time using the ⌘ key. For the basic stuff, these would be:

libboost_system.dylib or libboost_system-mt.dylib
libboost_thread.dylib or libboost_thread-mt.dylib
libCGAL_Core.dylib
libCGAL.dylib
libgmp.dylib
libmpfr.dylib

You might notice that these are actually symlinks to the actual files. Unfortunately, Xcode will make your code point to the actual files instead. This means that when you update your dependencies, your Xcode project will not build anymore. Just check which linked libraries are broken (they will be highlighted in red) and re-add them.