This is about compiling the GLFW library itself. For information on how to build applications that use GLFW, see Building applications.
GLFW uses CMake to generate project files or makefiles for a particular development environment. If you are on a Unix-like system such as Linux or FreeBSD or have a package system like Fink, MacPorts, Cygwin or Homebrew, you can install its CMake package. If not, you can download installers for Windows and macOS from the CMake website.
Once you have installed CMake, make sure that all other dependencies are available. On some platforms, GLFW needs a few additional packages to be installed. See the section for your chosen platform and development environment below.
The Windows SDK bundled with Visual C++ already contains all the necessary headers, link libraries and tools except for CMake. Move on to Generating build files with CMake.
Both the MinGW and the MinGW-w64 packages already contain all the necessary headers, link libraries and tools except for CMake. Move on to Generating build files with CMake.
Both Cygwin and many Linux distributions have MinGW or MinGW-w64 packages. For example, Cygwin has the mingw64-i686-gcc and mingw64-x86_64-gcc packages for 32- and 64-bit version of MinGW-w64, while Debian GNU/Linux and derivatives like Ubuntu have the mingw-w64 package for both.
GLFW has CMake toolchain files in the CMake/ directory that set up cross-compilation of Windows binaries. To use these files you add an option when running cmake to generate the project files or makefiles:
The exact toolchain file to use depends on the prefix used by the MinGW or MinGW-w64 binaries on your system. You can usually see this in the /usr directory. For example, both the Debian/Ubuntu and Cygwin MinGW-w64 packages have /usr/x86_64-w64-mingw32 for the 64-bit compilers, so the correct invocation would be:
For more details see the article CMake Cross Compiling on the CMake wiki.
Once you have this set up, move on to Generating build files with CMake.
Xcode comes with all necessary tools except for CMake. The required headers and libraries are included in the core macOS frameworks. Xcode can be downloaded from the Mac App Store or from the ADC Member Center.
Once you have Xcode installed, move on to Generating build files with CMake.
To compile GLFW for X11, you need to have the X11 packages installed, as well as the basic development tools like GCC and make. For example, on Ubuntu and other distributions based on Debian GNU/Linux, you need to install the xorg-dev package, which pulls in all X.org header packages.
Once you have installed the necessary packages, move on to Generating build files with CMake.
To compile GLFW for Wayland, you need to have the Wayland packages installed, as well as the basic development tools like GCC and make. For example, on Ubuntu and other distributions based on Debian GNU/Linux, you need to install the libwayland-dev package, which contains all Wayland headers and pulls in wayland-scanner, as well as the wayland-protocols and extra-cmake-modules packages.
Once you have installed the necessary packages, move on to Generating build files with CMake.
To compile GLFW for OSMesa, you need to install the OSMesa library and header packages. For example, on Ubuntu and other distributions based on Debian GNU/Linux, you need to install the libosmesa6-dev package. The OSMesa library is required at runtime for context creation and is loaded on demand.
Once you have installed the necessary packages, move on to Generating build files with CMake.
Once you have all necessary dependencies it is time to generate the project files or makefiles for your development environment. CMake needs to know two paths for this: the path to the root directory of the GLFW source tree (i.e. not the src subdirectory) and the target path for the generated files and compiled binaries. If these are the same, it is called an in-tree build, otherwise it is called an out-of-tree build.
One of several advantages of out-of-tree builds is that you can generate files and compile for different development environments using a single source tree.
To make an in-tree build, enter the root directory of the GLFW source tree (i.e. not the src subdirectory) and run CMake. The current directory is used as target path, while the path provided as an argument is used to find the source tree.
To make an out-of-tree build, make a directory outside of the source tree, enter it and run CMake with the (relative or absolute) path to the root of the source tree as an argument.
Once you have generated the project files or makefiles for your chosen development environment, move on to Compiling the library.
If you are using the GUI version, choose the root of the GLFW source tree as source location and the same directory or another, empty directory as the destination for binaries. Choose Configure, change any options you wish to, Configure again to let the changes take effect and then Generate.
Once you have generated the project files or makefiles for your chosen development environment, move on to Compiling the library.
You should now have all required dependencies and the project files or makefiles necessary to compile GLFW. Go ahead and compile the actual GLFW library with these files, as you would with any other project.
Once the GLFW library is compiled, you are ready to build your applications, linking it to the GLFW library. See Building applications for more information.
The CMake files for GLFW provide a number of options, although not all are available on all supported platforms. Some of these are de facto standards among projects using CMake and so have no GLFW_ prefix.
If you are using the GUI version of CMake, these are listed and can be changed from there. If you are using the command-line version of CMake you can use the ccmake ncurses GUI to set options. Some package systems like Ubuntu and other distributions based on Debian GNU/Linux have this tool in a separate cmake-curses-gui package.
Finally, if you don't want to use any GUI, you can set options from the cmake command-line with the -D flag.
BUILD_SHARED_LIBS determines whether GLFW is built as a static library or as a DLL / shared library / dynamic library.
GLFW_BUILD_EXAMPLES determines whether the GLFW examples are built along with the library.
GLFW_BUILD_TESTS determines whether the GLFW test programs are built along with the library.
GLFW_BUILD_DOCS determines whether the GLFW documentation is built along with the library.
GLFW_VULKAN_STATIC determines whether to use the Vulkan loader linked directly with the application.
USE_MSVC_RUNTIME_LIBRARY_DLL determines whether to use the DLL version or the static library version of the Visual C++ runtime library. If set to ON, the DLL version of the Visual C++ library is used.
GLFW_USE_HYBRID_HPG determines whether to export the NvOptimusEnablement and AmdPowerXpressRequestHighPerformance symbols, which force the use of the high-performance GPU on Nvidia Optimus and AMD PowerXpress systems. These symbols need to be exported by the EXE to be detected by the driver, so the override will not work if GLFW is built as a DLL.
If you wish to compile GLFW without its CMake build environment then you will have to do at least some of the platform detection yourself. GLFW needs a configuration macro to be defined in order to know what window system it's being compiled for and also has optional, platform-specific ones for various features.
When building with CMake, the glfw_config.h configuration header is generated based on the current platform and CMake options. The GLFW CMake environment defines GLFW_USE_CONFIG_H, which causes this header to be included by internal.h. Without this macro, GLFW will expect the necessary configuration macros to be defined on the command-line.
The window creation API is used to create windows, handle input, monitors, gamma ramps and clipboard. The options are:
If you are building GLFW as a shared library / dynamic library / DLL then you must also define _GLFW_BUILD_DLL. Otherwise, you must not define it.
If you are linking the Vulkan loader directly with your application then you must also define _GLFW_VULKAN_STATIC. Otherwise, GLFW will attempt to use the external version.
If you are using a custom name for the Vulkan, EGL, GLX, OSMesa, OpenGL, GLESv1 or GLESv2 library, you can override the default names by defining those you need of _GLFW_VULKAN_LIBRARY, _GLFW_EGL_LIBRARY, _GLFW_GLX_LIBRARY, _GLFW_OSMESA_LIBRARY, _GLFW_OPENGL_LIBRARY, _GLFW_GLESV1_LIBRARY and _GLFW_GLESV2_LIBRARY. Otherwise, GLFW will use the built-in default names.
For the EGL context creation API, the following options are available:
EGL/eglplatform.h header file for native handle types (fallback)Last update on Mon Jan 20 2020 for GLFW 3.3.2