Messages

1

General discussions / Premake

« on: September 12, 2011, 05:35:42 am »

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.

2

General discussions / Premake

« on: September 12, 2011, 04:24:46 am »

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

3

SFML projects / Premake Build System for SFML

« on: September 12, 2011, 04:20:44 am »

Hi,

I'm building a project with SFML using Premake as my build system. Since Premake is super cool, I figured other people would also want to use Premake with SFML in their projects. Premake is a great build system, and it makes it really easy to build cross-platform configurations. SFML support for that only makes it far better.

It makes me sad that everyone is adopting CMake when we have Premake. I shall still make the best of it, however, and I hope you will also.

I'm going to release this under the ZLib license, the same thing SFML uses (amazing license). I don't know if this is even legal, since it's got some SFML stuff in it, but I think it is. If it's not legal, or moral, or anything, tell me. I'm just trying to (over)protect myself.

It's kind of just a template right now. There's a bunch of information in the comments, so read them. This is just kind of me sharing a file right now, but it can be more in the future. I'm not going to go to those measures unless someone actually cares.

Well, here's the code. Have fun. (I know you will!)

4

General discussions / Premake

« on: September 12, 2011, 02:23:45 am »

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.

5

General discussions / Premake

« on: September 11, 2011, 03:00:50 pm »

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.

6

General discussions / Premake

« on: September 10, 2011, 07:48:24 pm »

It'd be a lot of work to update both build systems though.

7

General discussions / Premake

« on: September 10, 2011, 05:58:12 pm »

Don't fix something that ain't broken imo. Is there any problem with CMake? If not, leave it.

http://industriousone.com/debugdir

Works in Visual Studios. Enough said*.

EDIT: on that note, CMake may have no intention of adding this, judging by the way the write about it here. This may not be relevant for SFML except for the examples, but it'd be nice for SFML to use Premake as well as my own projects.

*Not really, I had more to say.