Scientific Computing

CMake macOS Xcode Environment

Related: GCC / Clang header clash on macOS

When macOS, Xcode, or Command Line Tools upgrades, build directories (including for CMake-based projects) often need to be refreshed. If the user has set custom environment variables concerning Xcode, they may need to be updated as well. Here are some important environment variables and CMake variables to check if problems occur after upgrading.

For a simple CMake project on macOS, CMakeCache.txt might include:

CMAKE_OSX_DEPLOYMENT_TARGET:STRING=

CMAKE_OSX_SYSROOT:PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX*.sdk

Having multiple directories under the following is fine:

  • /Library/Developer/CommandLineTools/SDKs
  • /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs

CMake can select the appropriate SDK by the user specifying environment variable SDKROOT or by selecting the SDK:

xcode-select --switch

The XCode versions that Homebrew targets can be found in xcode.rb.

Workarounds

If Homebrew GCC breaks after upgrading Xcode or Command Line Tools, try specifying an older SDK. For example, if g++-14 main.cpp -v shows a different (older) SDK than CMake and it works, try specifying that SDK in environment variable SDKROOT. Note that the SDK version corresponds to macOS version, not the XCode version. For example, if the latest SDK is MacOSX14.4.sdk, try using MacOSX13.3.sdk in “~/gcc.sh”:

export CC=gcc-14 CXX=g++-14 FC=gfortran-14

export SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/

and then source ~/gcc.sh before running cmake with a fresh build directory.

If a CMake build step fails, try copy-pasting the command and removing the -isysroot portion of the command. This is a clear clue the older SDK is (at least temporarily) needed till Homebrew updates its GCC formula.

GCC will tell where included files are coming from by adding the gcc -H flag. This tells what to specify for environment variable SDKROOT.

Example minimal project

Zoom audio toggle indicator

As per the Release Notes:

The Zoom app offers an option to play audio tones when muting or unmuting the microphone, providing enhanced accessibility for users with visual impairments or other disabilities. This setting is OFF by default and can be enabled from the Zoom Workplace app under Settings then Audio. When enabled, users will hear a tone, audible only to them, indicating the mute or unmute action.

CMake variables in SCRIPT role

When running CMake standalone scripts like cmake -P script.cmake this is the SCRIPT CMake role. Not all CMake information variables are set in SCRIPT role, in particular, the CMAKE_HOST* and CMAKE_SYSTEM* variables are not set as they are in PROJECT role.

This is a workaround for cmake -P SCRIPT role to get the CMAKE_HOST_* variables. It uses undocumented CMake-internal scripts, but they’ve been present since 2012 and may be unlikely to change.

message(STATUS "CMake ${CMAKE_VERSION}")

get_property(cmake_role GLOBAL PROPERTY CMAKE_ROLE)
if(cmake_role STREQUAL "SCRIPT")
  set(CMAKE_PLATFORM_INFO_DIR ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY})
  # define CMAKE_HOST*, CMAKE_SYSTEM*, etc.
  include(${CMAKE_ROOT}/Modules/CMakeDetermineSystem.cmake)
  # set booleans like CYGWIN
  include(${CMAKE_ROOT}/Modules/CMakeSystemSpecificInitialize.cmake)

  # needed by Modules/Platform/*.cmake
  include(${CMAKE_ROOT}/Modules/CMakeSystemSpecificInformation.cmake)

  # define CMAKE_SHARED_LIBRARY_SUFFIX, CMAKE_SHARED_LIBRARY_PREFIX, etc.
  include(${CMAKE_ROOT}/Modules/Platform/${CMAKE_SYSTEM_NAME}.cmake)
endif()

message(STATUS "CMAKE_SYSTEM:                ${CMAKE_SYSTEM}")
message(STATUS "CMAKE_SYSTEM_NAME:           ${CMAKE_SYSTEM_NAME}")
message(STATUS "CMAKE_SYSTEM_VERSION:        ${CMAKE_SYSTEM_VERSION}")
message(STATUS "CMAKE_SYSTEM_PROCESSOR:      ${CMAKE_SYSTEM_PROCESSOR}")
message(STATUS "CMAKE_HOST_SYSTEM:           ${CMAKE_HOST_SYSTEM}")
message(STATUS "CMAKE_HOST_SYSTEM_NAME:      ${CMAKE_HOST_SYSTEM_NAME}")
message(STATUS "CMAKE_HOST_SYSTEM_VERSION:   ${CMAKE_HOST_SYSTEM_VERSION}")
message(STATUS "CMAKE_HOST_SYSTEM_PROCESSOR: ${CMAKE_HOST_SYSTEM_PROCESSOR}")
message(STATUS "CMAKE_SHARED_LIBRARY_SUFFIX: ${CMAKE_SHARED_LIBRARY_SUFFIX}")
message(STATUS "CMAKE_SHARED_LIBRARY_PREFIX: ${CMAKE_SHARED_LIBRARY_PREFIX}")
message(STATUS "CMAKE_STATIC_LIBRARY_SUFFIX: ${CMAKE_STATIC_LIBRARY_SUFFIX}")
message(STATUS "CMAKE_STATIC_LIBRARY_PREFIX: ${CMAKE_STATIC_LIBRARY_PREFIX}")

Meson C++ standard with fallback

Meson can set a default C++ (or C) langauge standard level with fallback to older versions. This allows recent compilers to support the full functionality of the project code, while falling back for older compilers.

get_option('cpp_std') can be used for logic within meson.build if desired.

project('ffilesystem', ['cpp'],
default_options: ['c_std=c99', 'cpp_std=c++23,c++20,c++17', 'buildtype=release', 'b_ndebug=if-release'])

cpp_std = get_option('cpp_std')

message('C++ standard: ' + cpp_std)

The C / C++ code can use macro feature checks that detect compiler C++ / C standard support.

#if __cplusplus >= 201703L
// C++17 features
#endif

For C code likewise:

#if __STDC_VERSION__ >= 201112L
// C11 features
#endif

Related:

C feature macros that stdlib.h may need

When reading the documentation for a C library function, you may see a note that the function requires a feature test macro to be defined. This is common for functions that are not part of the C standard library but are part of POSIX or another standard. The feature test macro tells the compiler to include the necessary headers and definitions for the function.

Often the _DEFAULT_SOURCE macro is sufficient. Try doing in C BEFORE including the header file that defines the function:

#if defined(__linux__) && !defined(_DEFAULT_SOURCE)
#define _DEFAULT_SOURCE
#endif

#include <stdlib.h>

Switch CMake Generator to Ninja

The default CMake build generator is operating system dependent. In general many projects can benefit from increased build speed and especially rebuild speed of Ninja. Switch the default build generator on any platform by setting environment variable CMAKE_GENERATOR.

CMAKE_GENERATOR=Ninja

Ninja executable can be installed by any one of:

  • download
  • WinGet: winget install Ninja-build.Ninja
  • Python: pip install ninja
  • Homebrew: brew install ninja
  • Alpine Linux: apk add ninja-build

Add the location of the Ninja executable to environment variable $PATH or CMAKE_PROGRAM_PATH.

Note that Ninja work-alikes like Samurai “samu” might get installed by default by some package managers. These work-alikes might not have a new-enough Ninja API equivalent, so in those cases install the actual Ninja program.

If using Conan Package Manager, tell Conan to use Ninja by setting environment variable

CONAN_CMAKE_GENERATOR=Ninja

Check C++ random is working with CMake

The C++ STL <random> header may not be implemented correctly by some C++ compiler / CPU arch platforms. If a function using <random> is not essential to the program, avoid build errors by checking that <random> is working at configure time. This example checks that <random> is working with CMake.

include(CheckSourceCompiles)

check_source_compiles(CXX
"#include <random>
int main(){
  std::mt19937 mt_rand(0);
  return 0;
}"
HAVE_MERSENNE_TWISTER
)

add_executable(main main.cpp)
target_compile_definitions(main PRIVATE $<$<BOOL:${HAVE_MERSENNE_TWISTER}>:HAVE_MERSENNE_TWISTER>)

The “main.cpp” can have #ifdef HAVE_MERSENNE_TWISTER to conditionally compile code that uses <random>. This allows the rest of the program that doesn’t use this function to work without <random> or to fallback to a simpler RNG if suitable.

#ifdef HAVE_MERSENNE_TWISTER
#include <random>
#endif

#include <cstdlib>
#include <iostream>

void init_rand(){
#ifdef HAVE_MERSENNE_TWISTER
  std::mt19937 mt_rand(0);
#else
  std::cerr << "Warning: mt19937 not available\n";
#endif
}

UTM serial device in case no display on boot

For VM server images in particular, the main display of the VM may never activate. The UTM message is like:

display output is not active

This is solved by powering off the VM, and adding a Serial Device under the UTM VM settings. Rebooting will automatically popup a separate windows for the Serial terminal, where boot messages and login can be accomplished. Often the main display window will then start working.

Cross-compiler Raspberry Pi Pico

Microcontrollers generally use a different CPU architecture than the developer’s laptop. This implies a cross compiler is needed to build code for the microcontroller on the laptop. It’s straightforward to install the Raspberry Pi Pico ARM C / C++ cross-compiler on macOS, Windows, and Linux.

Please follow the section relevant to the laptop operating system. About 2..5 gigabytes of hard drive space is required by the Raspberry Pi Pico SDK and associated tools.

Git, CMake and a cross compiler are used by almost all full projects as well. This script will install the cross-compiler and other tools needed for the Raspberry Pi Pico SDK, or follow the manual process below.

#!/usr/bin/env bash

set -e

# determine OS and arch
case "$OSTYPE" in
linux*)
sudo apt update
sudo apt install git cmake g++ gcc-arm-none-eabi libnewlib-arm-none-eabi libstdc++-arm-none-eabi-newlib;;
darwin*)
brew install git cmake
brew install --cask gcc-arm-embedded;;
*)
echo "$OSTYPE not supported"
exit 1
esac

macOS

Homebrew install Git, CMake build system, and ARM cross-compiler by:

brew install cmake git

brew install --cask gcc-arm-embedded

The cross-compiler executables have a prefix “arm-none-eabi-” that are linked into $(brew --prefix)/bin for easy use from the command line.

It’s likely the macOS laptop has an Apple Silicon CPU. If so, it’s necessary to enable Rosetta. Rosetta enables most x86 apps on Apple Silicon at nearly full performance.

Note: if on macOS you get a build error like:

arm-none-eabi-gcc: fatal error: cannot read spec file ’nosys.specs’: No such file or directory

and you’ve installed the GCC cross-compiler via:

brew install --cask gcc-arm-embedded

Then something is wrong with the cross-compiler setup.

Linux

Install Git, CMake build system, and ARM cross-compiler on:

  • laptop/desktop with Ubuntu / Debian-like distros
  • full Raspberry Pi (e.g. Raspberry Pi 4)
apt update

apt install git make cmake g++ gcc-arm-none-eabi libnewlib-arm-none-eabi libstdc++-arm-none-eabi-newlib

Windows MSYS2 

pacman -S mingw-w64-ucrt-x86_64-arm-none-eabi-gcc

This takes about 2GB of storage.

Windows WSL

Windows Subsystem for Linux (WSL) is useful for many projects including the Raspberry Pi Pico SDK. WSL can be the easiest way to work with non-Windows projects on Windows.

The Ubuntu WSL process takes about 10 minutes depending on download speed. WSL can be installed via the Microsoft Store Ubuntu app. If the Microsoft Store isn’t available on the computer, it is also possible to install Ubuntu WSL manually.

WSL can access the native Windows filesystem. WSL sees the native Windows filesystem “C:” in WSL via “/mnt/c”. Use the native Windows drive under “/mnt/c/pico” from WSL. Then use Windows File Explorer in path “C:/pico” to drag and drop .uf2 file to Pico.

The cross-compiler install on WSL Ubuntu is just like plain Linux in the section above.

To make switching between Windows and WSL easier, optionally use Windows Terminal.

Alternative: Visual Studio

The Visual Studio cross-compiler setup is described in Section 9.2 of the Pico install guide.