Introduction to premake4


A while back I wrote a blog post based on my experiences using the CMake build system. The conclusion from this was that I found CMake to be a useful tool, but pretty painful to work with due to it using a custom scripting language and being quite lacking in the documentation and support departments. In short, it was something I tolerated rather than enjoyed using.

These issues meant I was open to alternatives, but I never looked for any until I read an AltDevBlogADay post on meta build systems which mentioned premake. Now premake was something I had looked at before when I was looking for a build system, however I discounted it at that time (I can’t remember why now) so I figured I’d take another look at it.

In trying it out, I found that I actually like it (far more than CMake). It’s nice and simple, uses Lua as it’s scripting language (so anything you can do in a standard Lua script, you can do in a premake script), and has excellent documentation and support.

Test Case

The test case I initially used was the same as my CMake test case. In this test case, I have two projects; one that should build as a static library, and one that should build as an executable linked against the static library. These projects are called “Core” and “Other” respectively and are arranged in a directory structure as shown below.

/               - The root SDK level
/Bin            - Folder to place the built executables in
/Lib            - Folder to place the built libraries in
/Source         - Contains the source code for the projects
/Source/Core    - Contains the source code for the Core project
/Source/Other   - Contains the source code for the Other project

The layout of the premake scripts we will use to generate the projects for this structure is entirely up to us. I chose to put everything in a single file as the script is very small, you can of course split the script into multiple files and include them into one another.

The premake Script

The premake script to generate the projects is surprisingly short when compared to CMake. It is shown below in its entirety.

-- premake 4 test solution
solution "SDK"

	-- setup common settings
	configurations { "Debug", "Release" }
	flags { "ExtraWarnings", "FatalWarnings", "FloatFast" }
	includedirs { "Source" }
	location "Build"

	-- setup the build configs
	configuration "Debug"
		defines { "DEBUG" }
		flags { "Symbols" }
		targetsuffix "_d"

	configuration "Release"
		defines { "NDEBUG" }
		flags { "Optimize" }

	-- "core" library project
	project "Core"
		kind "StaticLib"
		language "C++"
		targetdir "Lib"
		files { "Source/Core/**.h", "Source/Core/**.c", "Source/Core/**.cpp" }

	-- "other" executable project
	project "Other"
		kind "ConsoleApp"
		language "C++"
		targetdir "Bin"
		files { "Source/Other/**.h", "Source/Other/**.c", "Source/Other/**.cpp" }
		links { "Core" }

Seriously, that’s it. Hopefully most of that is self explanatory, with familiar terminology for anyone who has used Visual Studio.

I would explain it in detail, but honestly I think it would be insulting to do so. All the functions used in the script are explained on this page in full detail anyway; also since premake is so simple, it’s really only a slightly modified version of their sample script anyway.

To run the script and generate the projects, all you need to do is run “premake4 ” where “” is your chosen compiler, (“premake4 vs2008”, for example). For more details, see the premake quick start.


From using it, I feel that premake is a great start to what will hopefully end up as an excellent product. It isn’t as feature rich out of the box as CMake, however for my usage it is plenty powerful enough. The only thing I miss from CMake is its “finder” modules for linking in third party dependencies; I wrote a post on the premake support forums on this subject, including my current solution to the problem.

comments powered by Disqus