GLFW

- Documentation
- Download
- Media
- Community

- Main Page
- Related Pages
- Modules
- Data Structures
- Files

All Data Structures Files Functions Variables Typedefs Macros Modules Pages
Compiling GLFW

This is about compiling the GLFW library itself. For information on how to build applications that use GLFW, see the Building applications guide.

# Using CMake

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 simply install its CMake package. If not, you can download installers for Windows and OS X from the CMake website.

Note
  CMake only generates project files or makefiles. It does not compile the actual GLFW library. To compile GLFW, first generate these files for your chosen development environment and then use them to compile the actual GLFW library.

## Dependencies

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.

### Dependencies for Visual C++ on Windows

The Microsoft Platform SDK that is installed along with Visual C++ already contains all the necessary headers, link libraries and tools except for CMake. Move on to Generating build files with CMake.

### Dependencies for MinGW or MinGW-w64 on Windows

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.

### Dependencies for MinGW or MinGW-w64 cross-compilation

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 allow for easy cross-compilation of Windows binaries. To use these files you need to add a special parameter when generating the project files or makefiles:

1 cmake -DCMAKE_TOOLCHAIN_FILE=<toolchain-file> .

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:

1 cmake -DCMAKE_TOOLCHAIN_FILE=CMake/x86_64-w64-mingw32.cmake .

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.

### Dependencies for Xcode on OS X

Xcode comes with all necessary tools except for CMake. The required headers and libraries are included in the core OS X 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.

### Dependencies for Linux and X11

To compile GLFW for X11, you need to have the X11 and OpenGL header 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` and `libgl1-mesa-dev` packages. The former pulls in all X.org header packages and the latter pulls in the Mesa OpenGL development packages. Note that using header files and libraries from Mesa during compilation will not tie your binaries to the Mesa implementation of OpenGL.

Once you have installed the necessary packages, move on to Generating build files with CMake.

## 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.

Note
  This section is about generating the project files or makefiles necessary to compile the GLFW library, not about compiling the actual library.

### Generating files with the CMake command-line tool

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.

1 cd <glfw-root-dir>
2 cmake .

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.

1 mkdir glfw-build
2 cd glfw-build
3 cmake <glfw-root-dir>

Once you have generated the project files or makefiles for your chosen development environment, move on to Compiling the library.

### Generating files with the CMake GUI

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.

## 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 the Building applications guide for more information.

## CMake options

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, use the `ccmake` tool. Some package systems like Ubuntu and other distributions based on Debian GNU/Linux have this tool in a separate `cmake-curses-gui` package.

### Shared CMake options

`BUILD_SHARED_LIBS` determines whether GLFW is built as a static library or as a DLL / shared library / dynamic library.

`LIB_SUFFIX` affects where the GLFW shared /dynamic library is installed. If it is empty, it is installed to `${CMAKE_INSTALL_PREFIX}/lib`. If it is set to `64`, it is installed to `${CMAKE_INSTALL_PREFIX}/lib64`.

`GLFW_CLIENT_LIBRARY` determines which client API library to use. If set to `opengl` the OpenGL library is used, if set to `glesv1` for the OpenGL ES 1.x library is used, or if set to `glesv2` the OpenGL ES 2.0 library is used. The selected library and its header files must be present on the system for this to work.

`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.

### OS X specific CMake options

`GLFW_USE_CHDIR` determines whether `glfwInit` changes the current directory of bundled applications to the `Contents/Resources` directory.

`GLFW_USE_MENUBAR` determines whether the first call to `glfwCreateWindow` sets up a minimal menu bar.

`GLFW_USE_RETINA` determines whether windows will use the full resolution of Retina displays.

`GLFW_BUILD_UNIVERSAL` determines whether to build Universal Binaries.

### Windows specific CMake options

`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. It is recommended to set this to `ON`, as this keeps the executable smaller and benefits from security and bug fix updates of the Visual C++ runtime.

`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.

### EGL specific CMake options

`GLFW_USE_EGL` determines whether to use EGL instead of the platform-specific context creation API. Note that EGL is not yet provided on all supported platforms.

# Compiling GLFW manually

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 number of configuration macros to be defined in order to know what it's being compiled for and has many 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.

Three macros must be defined when compiling GLFW: one selecting the window creation API, one selecting the context creation API and one client library. Exactly one of each kind must be defined for GLFW to compile and link.

The window creation API is used to create windows, handle input, monitors, gamma ramps and clipboard. The options are:

- `_GLFW_COCOA` to use the Cocoa frameworks
- `_GLFW_WIN32` to use the Win32 API
- `_GLFW_X11` to use the X Window System
- `_GLFW_WAYLAND` to use the Wayland API (experimental and incomplete)
- `_GLFW_MIR` to use the Mir API (experimental and incomplete)

The context creation API is used to enumerate pixel formats / framebuffer configurations and to create contexts. The options are:

- `_GLFW_NSGL` to use the Cocoa OpenGL framework
- `_GLFW_WGL` to use the Win32 WGL API
- `_GLFW_GLX` to use the X11 GLX API
- `_GLFW_EGL` to use the EGL API

Wayland and Mir both require the EGL backend.

The client library is the one providing the OpenGL or OpenGL ES API, which is used by GLFW to probe the created context. This is not the same thing as the client API, as many desktop OpenGL client libraries now expose the OpenGL ES API through extensions. The options are:

- `_GLFW_USE_OPENGL` for the desktop OpenGL (opengl32.dll, libGL.so or OpenGL.framework)
- `_GLFW_USE_GLESV1` for OpenGL ES 1.x (experimental)
- `_GLFW_USE_GLESV2` for OpenGL ES 2.x (experimental)

Note that `_GLFW_USE_GLESV1` and `_GLFW_USE_GLESV2` may only be used with EGL, as the other context creation APIs do not interface with OpenGL ES client libraries.

If you are building GLFW as a shared library / dynamic library / DLL then you must also define `_GLFW_BUILD_DLL`. Otherwise, you may not define it.

If you are using the X11 window creation API, support for the following X11 extensions can be enabled:

- `_GLFW_HAS_XINPUT` to use XInput2 for high-resolution cursor motion (recommended)
- `_GLFW_HAS_XF86VM` to use Xxf86vm as a fallback when RandR gamma is broken (recommended)

If you are using the Cocoa window creation API, the following options are available:

- `_GLFW_USE_CHDIR` to `chdir` to the `Resources` subdirectory of the application bundle during glfwInit (recommended)
- `_GLFW_USE_MENUBAR` to create and populate the menu bar when the first window is created (recommended)
- `_GLFW_USE_RETINA` to have windows use the full resolution of Retina displays (recommended)

Note
  None of the GLFW header option macros may be defined during the compilation of GLFW. If you define any of these in your build files, make sure they are not applied to the GLFW sources.