Premake

[Svenstaro]

I feel rather comfortable in CMake and the script language is really the only thing I dislike. It is easy to make a cross-platform project with CMake and it has a lot of Find* scripts to locate things on various systems even when cross-compiling.

Premake might have all that but seriously, CMake works and isn't broken. What is the issue here?

Was the build system in place before CMake broken? Probably not.

It was. It was a bunch of project files and Makefiles all maintained manually and it probably was a PITA for Laurent to maintain. Also the Makefiles didn't allow for using system libs and they were a pain for cross-compiling.

[CodeRarity]

It was. It was a bunch of project files and Makefiles all maintained manually and it probably was a PITA for Laurent to maintain. Also the Makefiles didn't allow for using system libs and they were a pain for cross-compiling.

bro·ken
adjective
1.
not functioning properly; out of working order.

Annoying, maybe not "broken". Even though it was hard to maintain, it did indeed function properly. CMake can be seen the same way, kind of annoying.

Code: [Select]

if os.get() ~= "windows" then
print "Your operating system is not yet supported."
return
end

solution "Sortmania"
function AddSFMLLinks()
links { "opengl32", "winmm", "freetype", "glew", "jpeg", "openal32", "sndfile" }

configuration { "gmake", "windows" }
libdirs { "sfml/extlibs/libs-mingw" }

if string.startswith(_ACTION, "vs") then
configuration { "x32", "vs*" }
libdirs { "sfml/extlibs/libs-msvc/x86" }

configuration { "x64", "vs*" }
libdirs { "sfml/extlibs/libs-msvc/x64" }
end
end

configurations { "Debug", "Release" }
if string.startswith(_ACTION, "vs") then
platforms { "x32", "x64" }
end

project "SFML"
kind "StaticLib"
language "C++"

includedirs { "sfml/include", "sfml/extlibs/headers", "sfml/extlibs/headers/AL", "sfml/extlibs/headers/jpeg", "sfml/src" }
files { "sfml/src/**.cpp" }
defines { "SFML_STATIC" }

configuration "Debug"
targetdir "Debug"
defines { "DEBUG" }
flags { "Symbols" }

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

configuration "windows"
includedirs { "sfml/extlibs/headers/libsndfile/windows" }
excludes { "sfml/src/SFML/Window/OSX/**", "sfml/src/SFML/Window/Linux/**",
"sfml/src/SFML/System/Unix/**", "sfml/src/SFML/Network/Unix/**" }

project "Sortmania"
kind "WindowedApp"
language "C++"

includedirs { "src", "sfml/include" }
files { "src/**.cpp" }
defines { "SFML_STATIC" }
links { "SFML" }
AddSFMLLinks()

configuration "Debug"
targetdir "Debug"
defines { "DEBUG" }
flags { "Symbols" }

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

I was able to get SFML into my Premake4 solution like this, just by guess and check. It's only static, and only works on Windows (tested on MinGW, haven't linked to a project yet but the output looked about right), but I'll probably add more as I compile it on those systems. Since it's not complete, it's probably not as long as a final product would be. But still, it's much shorter and more readable than CMake scripts, and therefore more maintainable.

EDIT: Works in Visual Studios 2010 Professional.

EDIT2: Oh, I fixed stuff. And I successfully linked it into an example. I'm just going to put my whole project file here, to make it really easy for  other people to adopt Premake.

EDIT3: I'm moving this into a new thread, because I want to share my work with the community without stealing this thread. I think I have made my point.

[Svenstaro]

Looks like we are splitting hairs and are playing build system golf. Here is mine:

Code: [Select]

cmake_minimum_required(VERSION 2.8)

project(sfml)
file(GLOB sfml_SRC
    src/SFML/Audio/*.cpp
    src/SFML/Window/*.cpp
    src/SFML/Window/Linux/*.cpp
    src/SFML/System/*.cpp
    src/SFML/System/Unix/*.cpp
    src/SFML/Graphics/*.cpp
    src/SFML/Network/*.cpp
    src/SFML/Network/Unix/*.cpp)

set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake/Modules/")

find_package(OpenAL REQUIRED)
find_package(OpenGL REQUIRED)
find_package(Freetype REQUIRED)
find_package(GLEW REQUIRED)
find_package(JPEG REQUIRED)
find_package(X11 REQUIRED)
find_package(ZLIB REQUIRED)
find_package(Sndfile REQUIRED)

include_directories(${OPENAL_INCLUDE_DIR} ${OPENGL_INCLUDE_DIR}
    ${FREETYPE_INCLUDE_DIRS} ${GLEW_INCLUDE_PATH} ${JPEG_INCLUDE_DIR}
    ${X11_INCLUDE_DIR} ${ZLIB_INCLUDE_DIRS} ${SNDFILE_INCLUDE_DIR})

include_directories(src include)

add_library(sfml SHARED ${sfml_SRC})
target_link_libraries(sfml ${OPENAL_LIBRARY} ${OPENGL_LIBRARIES}
    ${FREETYPE_LIBRARIES} ${GLEW_LIBRARY} ${JPEG_LIBRARIES} ${X11_LIBRARIES}
    ${ZLIB_LIBRARIES} ${SNDFILE_LIBRARIES})

$ wc -l CMakeLists.txt
34 CMakeLists.txt

Anyway, I think this is rather silly. Why don't you spend your resources helping other open-source projects that actually don't have any proper build system? libtcod comes to mind. There are probably many others.

[CodeRarity]

What about your FindXXXX.cmake files? And all the files in your /cmake/Modules path, for that matter?

[Svenstaro]

Well you provide those that CMake doesn't provide by itself. Or you could find things the raw way which is also what Premake4 seems to be doing. In that case you don't need FindX files, obviously.

[CodeRarity]

What my project files would look like if I did something similar to what you have done with CMake files (moving the code to FindXXX.cmake files, essentially):

Code: [Select]

dofile "sfml/sfml_static.lua"
solution "Sortmania"
   AddSFML()

   project "Sortmania"
      kind "WindowedApp"
      language "C++"

      includedirs { "src" }
      files { "src/**.cpp" }
      LinkSFML()

      configuration "Debug"
         defines { "DEBUG" }
         flags { "Symbols" }

      configuration "Release"
         flags { "Optimize" }


If you don't think that's short, readable and manageable, you shouldn't be programming.

Here's a list of other ways why people should use Premake over CMake:

-Easier to NOT use Premake
For example, if you are only making your project on Windows, and you are using Visual Studios, it might be better for you to just generate the project files and add those to your solution. With CMake, you actually have to edit the vcxproj files (to get rid of the build step) in Notepad to make it not run CMake every time. Then you get to go through and delete CMakeLists files and find all of the little things CMake left behind. In Premake, you generate it, and delete the lua file, and you're done.

-No junk files ("build directory")
I hate generating a project in CMake and having an entire folder of irrelevant trash. I just want the project files. This disgusts me.

-It uses a scripting langauge
A lot of programmers know Lua (especially in the game industry, where it is used in multiple game engines). If you want to start using CMake, you have to learn an entirely new language, that's not elegant or even reasonably readable at all.

-Documentation
Premake has a nice "Scripting with Premake" tutorial section, in addition to pretty straightforward scripting reference. CMake has a generated, monolithic list of commands.