Building a Standalone Executable

Why a Single Executable?

The primary goal is portability. A single executable file can be run on any compatible machine without requiring the user to install dependencies or have specific library files (.dll on Windows, .so on Linux) in the right place. It "just works." This is the standard for professional, native applications and is exactly what we want for our telemetry engine.

To achieve this, we need to understand a fundamental step in the C++ compilation process: linking.

Linking: Assembling the Pieces

When you compile your C++ project, the compiler first translates each .cpp source file into an "object file" (.o or .obj). These object files contain machine code, but they are incomplete. If main.cpp calls a function defined in plotter.cpp, the main.o object file only contains a placeholder, or a reference, to that function.

The linker is the tool that resolves these references. It takes all your project's object files, finds the actual code for each function call, and combines them into a final executable. This process also applies to external libraries like GLFW.

There are two main ways to perform this linking: statically and dynamically.

To get a solid grasp of these two approaches, the advantages of each, and how they relate to the build process, please read the following article. It provides an excellent and comprehensive explanation.

Key Differences Summarized

For our goal of creating a single, cohesive executable, static linking is the clear choice.

Controlling Linking with CMake

You've been using CMake to build the project, but we've let it handle the details automatically. Now, we'll take explicit control.

CMake provides a standard way to control whether libraries are built as static or shared: the BUILD_SHARED_LIBS variable.

• If BUILD_SHARED_LIBS is ON, CMake will build libraries as shared (.dll, .so).
• If BUILD_SHARED_LIBS is OFF (the default if not set), CMake will build libraries as static (.a, .lib).

Many well-behaved open-source libraries, including GLFW, respect this variable. This gives us a powerful, top-level switch to control the entire build process.

The following resource from the official CMake tutorial explains how this works.

Modifying Your CMakeLists.txt for a Static Build

We can enforce static linking for our entire project, including dependencies fetched with FetchContent, by setting this variable at the top of our main CMakeLists.txt file.

Open your top-level CMakeLists.txt and add the following line near the beginning, right after your project(...) command:

cmake_minimum_required(VERSION 3.22)
project(TelemetryEngine)

# Set the default library type to STATIC for the whole project.
# This ensures that our libraries and any dependencies that respect this
# variable (like GLFW) are built as static libraries.
set(BUILD_SHARED_LIBS OFF CACHE BOOL "Build shared libraries")

# ... rest of your CMake file (add_executable, FetchContent, etc.)

By adding set(BUILD_SHARED_LIBS OFF ...):

1. Any add_library(...) calls in our project without an explicit STATIC or SHARED keyword will now produce static libraries.
2. When FetchContent downloads and configures GLFW, it will see that BUILD_SHARED_LIBS is OFF and configure itself to build glfw3.lib (or libglfw3.a) instead of a dynamic library.
3. When you call target_link_libraries(YourApp PRIVATE glfw), the linker will find the static version of GLFW and copy its necessary code directly into YourApp.exe.

The result is a single executable with no external dependencies on GLFW.

Verifying the Result

After you rebuild your project with the change to CMakeLists.txt, you can verify that it worked:

1. Check the File Size: Your final executable file (TelemetryEngine.exe or TelemetryEngine) should be significantly larger than it was before. This is because it now contains the code from all its dependencies.
2. Inspect Dependencies (Linux/macOS):
   • On Linux, you can run ldd ./YourAppName. You should no longer see libglfw.so in the list of dependencies.
   • On macOS, you can run otool -L ./YourAppName. You should no longer see a reference to libglfw.dylib.
3. Run from a New Location: The most definitive test is to copy only the executable file to a completely separate directory and run it. If it starts up, your static linking was successful.

Conclusion

You have now mastered a critical skill in C++ development: creating a self-contained, portable application. This step transforms your project from a developer-only build into a distributable piece of software, ready to be shared or added to your portfolio.

Key Takeaways:

• Linking is the final stage of compilation, where code from different object files and libraries is combined.
• Static Linking copies all necessary code into the final executable, creating a single, portable file. This is ideal for distributing applications.
• Dynamic Linking creates smaller executables that depend on external library files (.dll/.so) at runtime.
• In CMake, the BUILD_SHARED_LIBS variable is the conventional way to control whether libraries are built as STATIC or SHARED. Setting it to OFF is a clean way to enforce a static build for your entire project.

What's Next?

With a fully-featured and packaged application, the next and final step in this module is to improve the quality of our codebase. In the next lesson, you will Refactor code to improve modularity, separating data capture, processing, and visualization logic. This will make your project more maintainable, easier to understand, and more professional—a crucial step before moving on to final benchmarking.