It'll be awesome. 'nuff said. But you know, it's a kind of game engine / framework.

Requirements:

• CMake 3.2 or later
• lab132 toolbox setup

Platforms:

https://github.com/lab132/toolbox

Required libraries:

• glew
• ezEngine

Optional libraries:

• Catch (for unit tests)

TODO: More info here!

TL;DR: Use a folder named <krepel-repo>/workspace to put the stuff generated by CMake in.

We will use the CMake GUI and Visual Studio 2013 on a Windows platform. The krepel repo will be checked out at C:/krepel.

After the krepel repo was checked out, run the CMake GUI. CMake wants to know two paths: The one where the source code lives in, or rather the directory of the top-level CMakeLists.txt file, as well as where to generate stuff to. The krepel repo is set to ignore a top-level directory workspace, which is where we will point CMake to for the binary dir. As a result, CMake GUI should look like this now:

• Where is the source code: C:/krepel
• Where to build the binaries: C:/krepel/workspace/VS2013Win64

We won't point the binary dir directly to the workspace/ directory, since we might want to generate a different build system, such as Visual Studio 2015 or a Unix Makefile project.

After we hit Configure and then Generate, we can open the file C:/krepel/workspace/VS2013Win64/krepel.sln with Visual Studio and work there.

TL;DR: Add the file to the file system and re-generate the build system using CMake.

We are globbing the source files from our source directories, which has the advantage that we don't have to specify each file individually. The drawback of this, however, is that CMake won't notice new files there unless it is re-run. So you have two choices:

1. Run CMake once more using the CMake GUI and hitting Generate directly.
2. Modify any files tracked by CMake so it will know that it has to regenerate.

TL;DR: You can do this in <krepel-repo>/build/CMake/platforms/<system-name>.cmake. Don't forget to re-run CMake.