Compilers and IDEs

This page has been automatically translated using the Google Translate API services. We are working on improving texts. Thank you for your understanding and patience.

It's hard to write software that runs correctly and efficiently. So once a program works in one environment, you don't want to repeat much of the effort if you move it to a different compiler or processor or operating system. Ideally, it should need no changes whatsoever. Kernighan & Pike - The Practice of Programming.

We understand by portability the ability to compile and debug our programs on platforms other than those on which they were written, without having to touch a single line of code. By platform we understand the combination of a compiler and a CPU architecture. For example, v143_x64 refers to Visual Studio 2022 and Intel 64bit. In (Figure 1) we see the different steps in the code migration process.

• Working copy: A copy of the project's source code must exist on each machine. Normally this will be done through a version control system (SVN, Git, etc).
• CMake: will create or update a build project from source code using /src/CMakeLists.txt and the scripts in the /prj directory. This will be done fully automatically.
• Compile: Using Visual Studio, Xcode or GCC, the solution will be compiled and the libraries and executables included in it will be generated.
• Run/Debug: The binaries can now be run and debugged on the target platform.

1. Windows compilers

We can use any version of Visual Studio from 2005 to compile under Windows (Table 1). As we already saw in Quick start, the first thing we have to do is launch CMake on the source code:

	Compiler	Platform	Minimum O.S.
	Visual Studio 2022	v143_x64 (x86)	Vista
	Visual Studio 2019	v142_x64 (x86)	Vista
	Visual Studio 2017	v141_x64 (x86)	Vista
	Visual Studio 2015	v140_x64 (x86)	Vista
	Visual Studio 2013	v120_x64 (x86)	Vista
	Visual Studio 2012	v110_x64 (x86)	Vista
	Visual Studio 2010	v100_x64 (x86)	XP
	Visual Studio 2008	v90_x64 (x86)	XP
	Visual Studio 2005	v80_x64 (x86)	XP

cmake -G "Visual Studio 16 2019" -A x64 -T v120 -S ./src -B ./build

• -G is the version of the compiler (or generator in CMake jargon).

-G "Visual Studio 17 2022" -G "Visual Studio 16 2019" -G "Visual Studio 15 2017" -G "Visual Studio 14 2015" -G "Visual Studio 12 2013" -G "Visual Studio 11 2012" -G "Visual Studio 10 2010" -G "Visual Studio 9 2008" -G "Visual Studio 8 2005"

• -A is Intel 32 or 64 bit architecture:

-A x64 -A Win32

• -T is the Platform Toolset. If you omit this parameter, the last one supported by the compiler will be taken.

-T v143 -T v142 -T v141 -T v140 -T v120 -T v110 // For XP compatibility -T v141_xp -T v140_xp -T v120_xp -T v110_xp -T v100 -T v90 -T v80

• -S: Path where the CMakeLists.txt is located. Usually in the /src directory of the SDK.
• -B: Path where the build projects, binaries and temporary files will be generated.

Support for Visual Studio 8 2005 was removed in CMake 3.12. You must use an older version of CMake if you are still using VS2005. NAppGUI does NOT work with versions prior to VS2005.

NAppGUI does not offer support for non-x86, x64 architectures on Windows: ARM, Itanium, etc.

After running CMake, a VisualStudio solution will appear in the /build folder, NAppGUI.sln or whatever name is configured in project(NAppGUI) of the CMakeLists.txt. Open that solution and from Visual Studio, Build->Build Solution to compile Debug->Start Debugging to debug (Figure 2).

To change the version of Visual Studio, select another builder in CMake -G "Visual Studio 15 2017", close and reopen the solution.

1.1. Platform toolset

Starting with Visual Studio 2010, there is a decoupling between the editor and the compiler. The term Plaform Toolset identifies the compiler itself, which can continue to be used with more modern IDEs. If we do not specify anything, CMake will use the default toolset included in each version of VS, but it can be changed using the -T parameter of CMake (Table 2). For example, we can combine Visual Studio 15 2017 with the VS2013 toolset for Windows XP v120_xp:

cmake -G "Visual Studio 16 2019" -A Win32 -T v120_xp -S ./src -B ./build

You need to have each version of Visual Studio installed to use its toolset. There are "light" versions that install the build tools without the development environment.

1.2. Visual C++ Redistributable

By default, Visual Studio dynamically links the functions of the C standard library, which means that the .exe may not work on machines that do not have the VC++ DLLs (Figure 3). This forces applications to include a copy of MSVCRT.dll, VCRUNTIME.dll, ... or to install the famous Visual C++ Redistributable packages. to ensure that the application can run smoothly.

NAppGUI uses a reduced set of the C library, since it directly accesses the Windows API whenever possible. For this reason, all applications created with NAppGUI perform a static link (option /MT) of the necessary functions of the stdlib, avoiding dependencies at the cost of slightly increasing (a few Kb) the size of the executable. final. This ensures that applications will run smoothly on all Windows machines without the need for additional DLLs and without having to install the VC++ Redistributable.

NAppGUI applications do not require the Visual C++ Redistributable. They also do not use the MFC "Microsoft Foundation Classes" or the .NET platform.

1.3. WindowsXP support

Starting with VS2012, the Platform Toolset generates executables that are not compatible with WindowsXP. If we want our applications to run on this system, we must select the alternative toolset ending in _xp: v141_xp, v140_xp, v120_xp, v110_xp. Or v100, v90 or v80 (VS2010, 2008, 2005), which do directly support XP (Figure 4) .

WindowsXP support has been permanently removed in Visual Studio 2019. There is no Platform Toolset v142_xp.

Cannot create applications with NAppGUI that work on Windows prior to XP.

1.4. SSE support

With the Pentium III, Intel introduced an additional instruction set for floating point operations called SSE Streaming SIMD Extensions. This allows you to optimize mathematical calculations at the cost of losing compatibility, since applications that use SSE will not work on Pentium II or earlier models. In NAppGUI the v80_x86 and v90_x86 toolsets have been reserved for building applications compatible with older (Table 3) processors. Starting with v100_x86, SSE2 will be used in all toolsets.

SSE support is only disabled on 32-bit (x86) architectures. All 64-bit (x64) CPUs incorporate SSE2.

2. macOS compilers

To compile for Apple iMac, macBook and macMini we will need CMake and Xcode starting with version 3.2.6 (Table 4). NAppGUI allows you to build applications that work on MacOSX 10.6 Snow Leopard and later:

	Compiler	Minimum O.S.	Platform
	Xcode 14.1	Ventura	sdk13_1_x64 (arm)
	Xcode 13.4.1	Monterey	sdk12_3_x64 (arm)
	Xcode 12.5.1	Big Sur	sdk11_5_x64 (arm)
	Xcode 11.7	Catalina	sdk10_15_x64
	Xcode 10.3	Mojave	sdk10_14_x64
	Xcode 9.4.1	High Sierra	sdk10_13_x64
	Xcode 8.3.3	Sierra	sdk10_12_x64
	Xcode 7.3.1	El Capitan	sdk10_11_x64
	Xcode 6.4	Yosemite	sdk10_10_x64
	Xcode 6.2	Mavericks	sdk10_9_x64
	Xcode 5.1.1	Mountain Lion	sdk10_8_x64
	Xcode 4.6.3	Lion	sdk10_7_x64
	Xcode 3.2.6	Snow Leopard	sdk10_6_x64 (x86)

cmake -G "Xcode" -DCMAKE_DEPLOYMENT_TARGET="11.0" -DCMAKE_ARCHITECTURE="arm64" -S ./src -B ./build

• -G always "Xcode". Use xcode-select to toggle if you have multiple versions installed.
• -DCMAKE_DEPLOYMENT_TARGET. Minimum operating system that will be supported. Omitting it will set the Base SDK included in the Xcode version.

-DCMAKE_DEPLOYMENT_TARGET="13.1" // Ventura -DCMAKE_DEPLOYMENT_TARGET="13.0" // Ventura -DCMAKE_DEPLOYMENT_TARGET="12.4" // Monterey -DCMAKE_DEPLOYMENT_TARGET="12.3" // Monterey -DCMAKE_DEPLOYMENT_TARGET="12.2" // Monterey -DCMAKE_DEPLOYMENT_TARGET="12.0" // Monterey -DCMAKE_DEPLOYMENT_TARGET="11.5" // Big Sur -DCMAKE_DEPLOYMENT_TARGET="11.4" // Big Sur -DCMAKE_DEPLOYMENT_TARGET="11.3" // Big Sur -DCMAKE_DEPLOYMENT_TARGET="11.2" // Big Sur -DCMAKE_DEPLOYMENT_TARGET="11.1" // Big Sur -DCMAKE_DEPLOYMENT_TARGET="11.0" // Big Sur -DCMAKE_DEPLOYMENT_TARGET="10.15" // Catalina -DCMAKE_DEPLOYMENT_TARGET="10.14" // Mojave -DCMAKE_DEPLOYMENT_TARGET="10.13" // High Sierra -DCMAKE_DEPLOYMENT_TARGET="10.12" // Sierra -DCMAKE_DEPLOYMENT_TARGET="10.11" // El Capitan -DCMAKE_DEPLOYMENT_TARGET="10.10" // Yosemite -DCMAKE_DEPLOYMENT_TARGET="10.9" // Mavericks -DCMAKE_DEPLOYMENT_TARGET="10.8" // Mountain Lion -DCMAKE_DEPLOYMENT_TARGET="10.7" // Lion -DCMAKE_DEPLOYMENT_TARGET="10.6" // Snow Leopard

• -DCMAKE_ARCHITECTURE. arm64, x64, i386. The arm64 architecture is included starting with SDK 11.0 Big Sur. i386 was deprecated in macOS 10.13 High Sierra.

-DCMAKE_ARCHITECTURE="arm64" -DCMAKE_ARCHITECTURE="x64" -DCMAKE_ARCHITECTURE="i386"

NAppGUI does not support the creation of Apple's Fat binaries. You must indicate a single value in this field.

• -S: Path where the CMakeLists.txt is located. Usually in the /src directory of the SDK.
• -B: Path where the build projects, binaries and temporary files will be generated.

After running CMake, an Xcode solution will appear in the /build folder, NAppGUI.xcodeproj or whatever name is configured in project(NAppGUI) of the CMakeLists.txt. Opening the Xcode solution, we see the different projects that make it up, including Die and Dice. Select Die in the top left dropdown and then click Play or Product->Run (Figure 5). This will compile the program and launch it in debug mode, where we can set breakpoints to inspect the stack and the values ​​of the variables.

2.1. Base SDK and Deployment Target

Every year, Apple releases a new version of macOS, accompanied by a new SDK and an update to Xcode that includes the SDK. This is called the Base SDK.

Base SDK is the version included in each new major version of Xcode, which matches the latest version of the macOS system released on the market.

Apple has a much more restrictive policy than Microsoft regarding the compatibility of applications with previous versions of the operating system. By default, a program compiled with SDK 10.14 (macOS Mojave) will not work on the immediately preceding macOS High Sierra (Figure 6).

To avoid this problem, and for applications to work on older macOS, there is the Deployment Target parameter. Using it will trigger a macro that will override the new features of the Base SDK. This will allow the program to run on older versions at the cost, of course, of not having access to the latest iMac features. You will be able to select the Deployment Target required by your project through the -DCMAKE_DEPLOYMENT_TARGET parameter, as we have already seen in the previous section.

Xcode 14 deprecates Deployment Targets below 10.13 (Figure 7). Use Xcode 13 if you want compatibility with Mac OSX 10.12 Sierra and earlier.

Xcode 8 deprecates Deployment Targets below 10.9 (Figure 8). Use Xcode 7 if you want compatibility with Mac OSX 10.8 Mountain Lion and earlier.

2.2. xcode-select

We have already seen that CMake only offers one generator for Xcode (-G "Xcode"), although it is possible to have multiple versions installed on the same machine, each within its own bundle Xcode.app. There will always be a default Xcode on the system (the most recent one) but it can be changed using the xcode-select utility:

xcode-select -p
/Applications/Xcode.app/Contents/Developer

sudo xcode-select -s /Applications/Xcode8.app/Contents/Developer

sudo xcode-select -r

You will need to run cmake -G "Xcode"... again each time you use xcode-select for your project to update the compiler change.

2.3. macOS ARM

In November 2020 Apple launches its new line of desktop and laptop computers (iMac, macBook and macMini) based on the Apple M1 processor with ARM (Figure 9) architecture. Although they are capable of running programs compiled for Intel x64 using the Rosetta 2 (Figure 10) program, the ideal would be to compile our applications for the new architecture in order to optimize the executables as much as possible.

NAppGUI supports building for the Apple ARM architecture. You just need to include the -DCMAKE_ARCHITECTURE="arm64" option in CMake, as we saw in the previous section.

You can compile the M1 architecture from Intel x64 machines, but you won't be able to debug the executables.

M1 architecture is only available for Big Sur system (macOS 11.0) and later.

2.4. macOS 32bits

Since the macOS High Sierra release, Apple has declared the 32-bit architecture obsolete, issuing notices to users in the case of detecting i386 (Figure 11) executables. As of Xcode 10, (Figure 12) cannot be compiled on this architecture.

Support for 32bit applications is gone for good in macOS Catalina, which only allows running 64bit applications.

This makes some sense since all Intel-based iMac models feature 64-bit processors, except for a few 2006 models in white polycarbonate that mounted the 32-bit Intel Core Duo (Figure 13) . These iMacs supported Mac OSX 10.6 Snow Leopard at most, with a 64-bit CPU being a fundamental requirement as of 10.7 Lion. To compile without problems in 32bits you must use, at most, Xcode 6 (Figure 14).

3. Linux compilers

For Linux versions, we will use the gcc (Table 5) compiler and the make tool to generate the binaries, but there is no development environment " official" as it happens in Windows and macOS. To carry out an elementary configuration of our equipment, type the following commands in a terminal:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

// Development tools
sudo apt-get install build-essential
sudo apt-get install git
sudo apt-get install cmake

// Development libraries
sudo apt-get install libgtk-3-dev
sudo apt-get install libglu1-mesa-dev freeglut3-dev mesa-common-dev
sudo apt-get install libcurl4-openssl-dev

// GTK Inspector (Ctrl+D when debugging)
gsettings set org.gtk.Settings.Debug enable-inspector-keybinding true

// Check system libraries version
pkg-config --modversion gtk+-3.0
3.24.20

pkg-config --modversion libcurl
7.68.0

	Minimum O.S.	Compiler	Toolkit	Platform
	Ubuntu 22.04 LTS	GCC 11.2.0	GTK 3.24.33	gcc11_gtk3_x64
	Ubuntu 20.04 LTS	GCC 9.3	GTK 3.24.20	gcc9_gtk3_x64
	Ubuntu 18.04 LTS	GCC 7.5	GTK 3.22.30	gcc7_gtk3_x64
	Ubuntu 16.04 LTS	GCC 5.4	GTK 3.18.9	gcc5_gtk3_x64 (x86)
	Ubuntu 14.04 LTS	GCC 4.8.4	GTK 3.10.8	gcc4_8_gtk3_x64 (x86)
	Ubuntu 12.04 LTS	GCC 4.6.3	GTK 3.4.2	gcc4_6_gtk3_x64 (x86)
	Raspbian 11 Bullseye	GCC 10.2.1	GTK 3.24.24	gcc10_gtk3_arm64
	Raspbian 10 Buster	GCC 8.3.0	GTK 3.24.5	gcc8_gtk3_arm
	Raspbian 9.1 Strech	GCC 6.3.0	GTK 3.22.11	gcc6_gtk3_arm
	Raspbian 8.0 Jessie	GCC 4.9.2	GTK 3.14.5	gcc4_9_gtk3_arm

Just like we did on Windows and macOS, we run cmake to generate the build project:

cmake -G "Unix Makefiles" -DCMAKE_BUILD_CONFIG="Debug" -DCMAKE_ARCHITECTURE="x64" -DCMAKE_TOOLKIT="GTK3" -S ./src -B ./build

• -G always "Unix Makefiles". Additionally, you can create projects for the main IDEs available in Linux:

-G "Unix Makefiles" -G "CodeBlocks - Unix Makefiles" -G "CodeLite - Unix Makefiles" -G "Sublime Text 2 - Unix Makefiles" -G "Kate - Unix Makefiles" -G "Eclipse CDT4 - Unix Makefiles"

• -DCMAKE_BUILD_CONFIG. Unlike Visual Studio and Xcode, Make does not support the creation of multi-configuration projects. It must be indicated at the time of generation:

-DCMAKE_BUILD_CONFIG="Debug" -DCMAKE_BUILD_CONFIG="Release" -DCMAKE_BUILD_CONFIG="ReleaseWithAssert"

• -DCMAKE_ARCHITECTURE. x64, i386, arm, arm64. Cross-compiling is not allowed on Linux. We must select the same architecture as the host machine. This parameter can be omitted, it will be set automatically.

-DCMAKE_ARCHITECTURE="x64" // Only in Linux Intel 64bits hosts -DCMAKE_ARCHITECTURE="i386" // Only in Linux Intel 32bits hosts -DCMAKE_ARCHITECTURE="arm" // Only in Linux ARM 32bits hosts -DCMAKE_ARCHITECTURE="arm64" // Only in Linux ARM 64bits hosts

• -DCMAKE_TOOLKIT. As of today, the only option available is "GTK3", since NAppGUI does not support other graphical toolkits. This parameter can be omitted, it will be set automatically.

-DCMAKE_TOOLKIT="GTK3"

• -S: Path where the CMakeLists.txt is located. Usually in the /src directory of the SDK.
• -B: Path where the build projects, binaries and temporary files will be generated.

After executing cmake we will have, in the /build folder, a series of Makefiles ready to compile the project.

cmake --build ./build -j 4

...
[ 93%] Linking CXX executable ../../Debug/bin/DrawBig
[ 93%] Linking CXX executable ../../Debug/bin/GuiHello
[ 93%] Built target DrawBig
[ 94%] Building C object howto/drawhello/CMakeFiles/DrawHello.dir/resgen/res_drawhello.c.o
[ 94%] Linking CXX executable ../../Debug/bin/Col2dHello
[ 98%] Built target GuiHello
[ 98%] Building C object howto/drawimg/CMakeFiles/DrawImg.dir/resgen/res_drawimg.c.o
[ 98%] Linking CXX executable ../../Debug/bin/UrlImg
[ 98%] Linking CXX executable ../../Debug/bin/DrawHello
[ 98%] Built target Col2dHello
[ 98%] Linking CXX executable ../../Debug/bin/ColorView
[ 98%] Built target UrlImg
[ 98%] Built target DrawHello
[ 99%] Linking CXX executable ../../Debug/bin/DrawImg
[100%] Built target ColorView
[100%] Built target DrawImg

Once the compilation is finished, we can launch the executables directly from the terminal:

./build/demo/die/Debug/Die

If you're fairly comfortable with gdb, you can try debugging the code directly from the (Figure 15) terminal. Later we will see how to do it using Eclipse and Visual Studio Code.

gdb ./build/demo/die/Debug/Die
(gdb) run
...

3.1. GTK+3

Unlike Windows and macOS, Linux supports a multitude of desktop environments based on different libraries (or toolkits), GTK and Qt being the two most famous. NAppGUI uses GTK+3 for the graphical part since it is the base of the Gnome, Xfce, Lxde, etc, (Table 6) environments present in many of the most widespread distributions. GTK+3 will be present naturally in all of them, with no other additional dependencies being necessary. Of course, to compile under GTK+3 we will have to install the developer version, as we saw at the beginning of this section.

	Environment	Distributions
	Gnome	Ubuntu, Debian, Fedora, Red Hat, CentOS, Manjaro, Suse, Arch, ...
	Xfce	Xubuntu, Debian, Fedora, Manjaro, ...
	Lxde	Lubuntu, Raspbian, Debian, Fedora, Mandriva, ...
	Cinnamon	Mint, Debian, Ubuntu, Fedora, OpenSuse, ...
	Mate	Ubuntu Mate, Mint, Debian, Fedora, OpenSuse, ...
	Pantheon	Elementary OS
	Sugar

3.2. Multiple versions of GCC

Although every Linux distribution comes with a "canonical" version of GCC, it is possible to have several installed on the same machine and switch between them much like we did on macOS with xcode-select. To do this we will use the Linux update-alternatives command. We assume that we are on Ubuntu 18.04 LTS:

gcc --version
gcc 7.5.0

sudo apt-get install gcc-6 g++-6

sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-7 60 --slave /usr/bin/g++ g++ /usr/bin/g++-7
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-6 50 --slave /usr/bin/g++ g++ /usr/bin/g++-6

sudo update-alternatives --set gcc /usr/bin/gcc-6
gcc --version
gcc 6.5.0
g++ --version
g++ 6.5.0

sudo update-alternatives --auto gcc
gcc --version
gcc 7.5.0
g++ --version
g++ 7.5.0

3.3. Linux 32bits

To compile 32bit applications from a 64bit Ubuntu system it is necessary to install the multilib package:

sudo apt-get install gcc-multilib

But there are currently problems with cross-compiling that includes the GTK+ library, so it won't be possible to use the same machine development to build on both architectures, just like it does on Windows. Console applications or libraries that do not access GTK can be compiled in 32bit from a 64bit computer.

It is not possible to compile in 32bits from a 64bit Ubuntu system applications that use GTK+3. You must use a 32-bit Linux system for this.

3.4. Linux ARM

The ARM Advanced RISC Machine architecture is the predominant one in the market for embedded devices such as smartphones and tablets. Currently, NAppGUI does not offer support for the development of iOS/Android mobile applications, but it does support other types of boards that support "desktop" versions of Linux ARM, such as the Raspberry PI. To port our code to the Raspberry Pi we must follow the same steps as in Ubuntu Linux (Figure 16). Both distributions are based on Debian, so GCC, CMake and Make are available directly via apt-get.

3.5. Eclipse CDT

Working directly with the terminal gives us great flexibility when configuring our own tools. Going back to the console and typing cmake --build ./build -j 4 will recompile everything you need. However, using GDB directly will be quite tedious, so the use of an integrated debugger (or IDE) becomes almost essential. For the development of NAppGUI we intensively use Eclipse CDT. This environment will allow us to program with a methodology similar to that of Visual Studio and Xcode: Set breakpoints, inspect the stack and variables, search for files within the code directory, multiple edits, massive searches, etc.

The only difference is that we will have to use the -G "Eclipse CDT4 - Unix Makefiles" generator in CMake which, in addition to the Makefile, will create the . cproject and .project required to import the project into Eclipse.

Open Eclipse and do File->Import->Existing Projects into Workspace. A dialog box will appear where we indicate the build directory that we have configured in CMake (/build). Eclipse will open the project, placing a tree with all the files on the left and we will compile with Project->Build All. When debugging (Die in this case) we will create a profile from Run->Debug Configurations->C/C++ Application. Click [Search Project...] and select Die from the dropdown list. Finally we press [Debug] to debug the application interactively (Figure 17).

Some interesting Eclipse CDT options under Window->Preferences.

• Run/Debug->Launching->Terminate and Relaunch while launching.

Using Eclipse is only a recommendation. You have total freedom to use the tools that you consider best.

3.6. Visual Studio Code

Another interesting environment to develop on Linux is Visual Studio Code. With the appropriate extensions, it is possible to work in C/C++ with CMake in a very comfortable and fluid way. To install it:

sudo apt-get install code

We added, at a minimum, the C/C++ Extension Pack which will also include support for CMake (Figure 18).

We open our project with Open Folder. Later, we run CMake from the environment itself: [F1]->CMake:Configure. The first time, VSCode will ask for the location of the CMakeLists.txt main (Figure 19) (/src/CMakeLists.txt).

After the configuration we can compile with [F1]->CMake:Build. In the Output tab of VSCode we will see the evolution of the process:

[build] [ 97%] Building C object demo/die/CMakeFiles/Die.dir/resgen/res_die.c.o
[build] [ 98%] Built target Bode
[build] [ 98%] Building C object demo/products/CMakeFiles/Products.dir/products.c.o
[build] [ 98%] Built target Fractals
[build] [ 98%] Building C object demo/products/CMakeFiles/Products.dir/prview.c.o
[build] [ 99%] Linking CXX executable ../../Debug/bin/Die
[build] [100%] Building C object demo/products/CMakeFiles/Products.dir/resgen/res_products.c.o
[build] [100%] Built target Die
[build] [100%] Linking CXX executable ../../Debug/bin/Products
[build] [100%] Built target Products

To debug, the first thing is to select the target (or executable) with [F1]->CMake:Set Debug Target (Figure 20).

And we launch the debugger with [F1]->CMake:Debug (Figure 21).

4. Configurations

A NAppGUI application can be compiled in three different configurations, depending on the level of debugging we need.

• Debug: Includes debugging information in the binaries and does not perform code optimizations. It is the developer version.
• Release: Remove debug information and perform all possible optimizations. It is the version for the user.
• ReleaseWithAssert: It is the Release version, but leaving the Asserts statements active. It is aimed at the end user, but in cases where it is necessary to obtain detailed information on possible anomalies, at the cost of a decrease in the overall performance of the program.

Both Visual Studio and Xcode are multi-configuration environments, that is, we can switch between one and the other directly from the editor itself. In Visual Studio we have a dropdown at the top of the (Figure 22) editor.

In Xcode it is a bit more hidden. We do Product->Scheme->Edit Scheme. A popup window will appear. Select Run->Info->Build Configuration (Figure 23).

Unfortunately, Unix make does not support multiple configurations. This forces us to pass the CMAKE_BUILD_CONFIG (Figure 24) property to set the configuration in CMake before building the Makefiles. We must re-run cmake -S ./src -B ./build if we change the configuration, for the new configuration to take effect.