Allegro.cc - Online Community

Allegro.cc Forums » Off-Topic Ordeals » Premake (an alternative to Cmake)

This thread is locked; no one can reply to it. rss feed Print
Premake (an alternative to Cmake)
NiteHackr
Member #2,229
April 2002

I'm curious on people's thoughts on PREMAKE (http://industriousone.com/premake)? It seems to me to be a better alternative to CMAKE. It uses LUA rather than it's own proprietary scripting language and you only need to run it once.

Where I learned about it was I was looking at this modern OpenGL tutorial/book website (http://www.arcsynthesis.org/gltut/Building%20the%20Tutorials.html) and this section is about building their tutorials. Scroll down to the "Necessary Utilities" section and this is what it says:

Quote:

In order to build everything, you will need to download the Premake 4 utility for your platform of choice.

Premake is a utility like CMake: it generates build files for a specific platform. Unlike CMake, Premake is strictly a command-line utility. Premake's build scripts are written in the Lua language, unlike CMake's build scripts that use their own language.

Note that Premake only generates build files; once the build files are created, you can use them as normal. It can generate project files for Visual Studio, Code::Blocks, and XCode, as well as GNU Makefiles. And unless you want to modify one of the tutorials, you only need to run Premake once for each tutorial.

The Premake download comes as a pre-built executable for all platforms of interest, including Linux.

...it sounds quite nice and I think it may be a good alternative to CMake.

I don't know much about these things, so perhaps there is more to this than I am seeing.

SiegeLord
Member #7,827
October 2006
avatar

Quote:

And unless you want to modify one of the tutorials, you only need to run Premake once for each tutorial.

Dunno about much else, but this is the same as CMake... i.e. you only run it once and then reuse the build files.

Anyway, premake appears to have some development issues... the release I see on the webpage only supports MSVC 10, while CMake supports up to 12. So, from my point of view, it's a nice idea, but not very practical.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

beoran
Member #12,636
March 2011

I used premake for a while and it was nice, and easier than cmake. But I had to switch back to cmake because premake is not actively developed anymore.... Too bad.

bamccaig
Member #7,536
July 2006
avatar

I find all of these competing systems troublesome because they seem to fail to do the one thing that everybody really wants. For my own use I find plain Makefiles are easy enough to use...

I moved my contrived rot project over to premake4 a few years back as a test. While it was simple enough to get that trivial example to build, it's still just a pain in the ass for me to build it because I typically don't have premake4 installed... Nobody does. So that's one more dependency (if not several; I forget what it uses for a Lua interpreter), often not even distributed by *nix package repositories, that users need to install to use your software. And then they need to learn how to use it if their needs are non-standard...

A Makefile is superior. If you need something smarter than that you're probably better off using your preferred shell language of choice. Or perhaps Perl if you need more than that (or Win32 portability, without the need for Cygwin or MSYS; though honestly both are better than plain Win32; even Perl hates Win32).

Perl has several competing systems as well and it's frustrating to have to learn new things as they come along. That said, they do seem to have things pretty well sorted out. I've only ever written a simple Makefile.PL. There are also Build.PL and some kind of Dist::Zilla specification whose standard file name I don't even know... In any case, they all seem to achieve describing the process in an efficient manner.

That is more or less what is needed. Some way to configure "install locations", "library locations", "header file locations", blah blah blah, both for the system and for the software "distribution" (i.e., the thing you're building). From there, knowing what kind of language and how to preprocess, compile, and link; as necessary. As well as pass the appropriate flags. It turns out that these things are actually really complicated. The more you try to abstract them the more of a mess you create trying.

That's where a Makefile comes in handy. It is a well understood format, well supported across platforms, easy for end users to invoke, and in many cases easy to write and maintain. If you want to do some fancy auto-detection of dependencies then you might have some fun on your hands, but honestly I don't find Allegro 5's auto-detection the least bit useful. "[Build successful!]"

Excellent. Oh, wait, it won't do any of the things that I need it to. It saw that I was missing virtually all of the dependencies and just skipped everything useful... To me, if you are building software you probably want every feature it has under normal circumstances. In the worst case, the developers can probably predict which features most people don't want and exclude them by default. From there, it's trivial even with Makefiles to offer macros and environment variables to toggle things on and off explicitly as needed. The point is, the usual case wants you to build them a "full" build without extraneous stuff that nobody wants, and exceptional cases will need to do extra work regardless (but they're exceptional and few and have to RTFM regardless of what you do)...

Makefiles have the benefit of being low-level. You can do anything with them, and you don't have to fight with a custom language to do it (Correction: Obviously Makefiles have their own custom language, but it's minimal and long standardized, well documented and understood, and just shells out for the meat and potatoes). Premake4 might have been using a standard language, but the API was still custom so that's really the same thing. It isn't the syntax people have trouble with (mostly). It's knowing the goddamn possibilities and limitations.

If you really want to help me out, give me a package format that detects which distro it is on, tells you which packages will satisfy its dependencies, and give a --fuck-off-and-work option to just do the right thing automatically. Obviously a package system will be needed on stupid shit platforms like Windows to make it cross-platform, and obviously this will never happen because Windows and OS X are cesspools of incompetence and ignorance. Basically it doesn't get much easier than Makefiles in the real world. Individual communities can make things better, but it's damn hard to create something better that fits all languages and platforms.

I still have trouble using cmake to build Allegro. At least, to build the Allegro that I actually want. I don't think it adds anything up front, and from what I've seen of the actual configuration it's still a brain fuck that is nontrivial to understand or edit...

pkrcel
Member #14,001
February 2012

Cmake takes alot of bad press, but it's still a good system, I'd say.

It's not as easily maintainable as it could be, so diving into someone else's project might prove difficult, but starting from scratch is as good as anything else....then again it's more comprehensible than the configure scripts to me.

It's decently cross platform and it's easily extensible, thou you need to spend a little while with trial & error since many things aren't straightforward.

The proprietary scripting language in my view it's not a big disvantage, since it does not bring in any dependency and does its job.

It has a good IDE that supports it out of the box (QtCreator) for anyone that wants to write projects that woudl support it.

Last but not least, I really don't get what's wrong on the USER side of CMAKE since a lot of people report SO many difficulties.....most everyone comes from autotools and I really don't get HOW cmake could be deemed LESS friendly to the user.

NO build system architecture will ease your way through dependencies, so I really don' get it.

The REAL big NO-NO of CMAKE is documentation in my opinion: it REALLY sucks big time, but astonishingly so...its' not only bad, it's awful.

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

bamccaig said:

Makefiles have the benefit of being low-level. You can do anything with them, and you don't have to fight with a custom language to do it (Correction: Obviously Makefiles have their own custom language, but it's minimal and long standardized, well documented and understood, and just shells out for the meat and potatoes).

Does the BS ever stop coming out of your mouth? Makefiles are complicated and ugly with a lot of rules to memorize. There's a reason people use Cmake, and it is because they don't want to write makefiles. :/

bamccaig said:

it's still just a pain in the for me to build it because I typically don't have premake4 installed... Nobody does.

You don't need premake installed, you need lua installed, and that comes with an easy installer. It's nothing different than installing cmake.

Back OT :
Premake shows a lot of promise, but it has its quirks too. For example, here is an old premake file Trezker and I used when we were working on a cross-platform clipboard :

#SelectExpand
1lib_name = "clipboard" 2dependencies = { } 3 4solution (lib_name) 5 configurations { "Debug", "Release" } 6 7 project (lib_name) 8 kind "StaticLib" 9 language "C" 10 location "build" 11 targetdir "build/lib" 12 includedirs { "include" } 13 14 configuration "Debug" 15 defines { "DEBUG" } 16 flags { "Symbols" } 17 18 configuration "Release" 19 defines { "NDEBUG" } 20 flags { "Optimize" } 21 22 configuration "linux" 23 files { "src/linux.c" } 24 25 configuration "windows" 26 files { "src/windows.c" } 27 28-- ex_dependencies = {"allegro","allegro_image" } 29 examples = os.matchfiles("examples/*.c") 30 for index, name in pairs(examples) do 31 sname = name:sub(10, name:len()-2); 32 project (sname) 33 kind "ConsoleApp" 34 language "C" 35 location "build" 36 files { name } 37 includedirs { "src" } 38 links (lib_name) 39-- links (ex_dependencies) 40 targetdir "build/examples" 41 42 configuration "Debug" 43 defines { "DEBUG" } 44 flags { "Symbols", "ExtraWarnings" } 45-- links {"alld"} 46 configuration "Release" 47 defines { "NDEBUG" } 48 flags { "Optimize", "ExtraWarnings" } 49-- links {"alleg"} 50 end 51 52slash = "/" 53if os.is("windows") then 54 slash = "\\" 55end 56 57newoption { 58 trigger = "dir", 59 value = "path", 60 description = "Choose a path to install dir", 61} 62 63-- note : os.matchfiles expects directory separators to be forward slashes 64newaction { 65 trigger = "install", 66 description = "Install the software", 67 execute = function () 68 -- copy files, etc. here 69 70 libdir = _OPTIONS["dir"].."lib".."/" 71 os.mkdir(libdir); 72 files = os.matchfiles("build/lib/*") 73 print ("") 74 print ("Installing lib files to " .. libdir) 75 for k, f in pairs(files) do 76 print ("Copying " .. f) 77 success , errormsg = os.copyfile(f, libdir..getshortfilename(f)) 78 if (success == nil) then 79 print(errormsg) 80 end 81 end 82 83 includedir = _OPTIONS["dir"].."include/"..lib_name.."/" 84 os.mkdir(includedir); 85 files = os.matchfiles("src/*.h") 86 print ("") 87 print ("Installing header files to " .. includedir) 88 for k, f in pairs(files) do 89 print ("Copying " .. f) 90 success , errormsg = os.copyfile(f , includedir..getshortfilename(f)) 91 if (success == nil) then 92 print(errormsg) 93 end 94 end 95 96 end 97} 98 99newaction { 100 trigger = "uninstall", 101 description = "Uninstall the software", 102 execute = function () 103 104 libdir = _OPTIONS["dir"].."lib".."/" 105 files = os.matchfiles("build/lib/*") 106 print ("") 107 print ("Uninstalling lib files from " .. libdir) 108 for k, f in pairs(files) do 109 print ("Removing " .. f) 110 success , errormsg = os.remove(libdir..getshortfilename(f)) 111 if (success == nil) then 112 print(errormsg) 113 end 114 end 115 116 includedir = _OPTIONS["dir"].."include/"..lib_name.."/" 117 files = os.matchfiles("src/*.h") 118 print ("") 119 print ("Uninstalling header files from " .. includedir) 120 for k, f in pairs(files) do 121 print ("Removing " .. f) 122 success , errormsg = os.remove(includedir..getshortfilename(f)) 123 if (success == nil) then 124 print(errormsg) 125 end 126 end 127 print ("Removing "..includedir) 128 success , errormsg = os.rmdir(includedir) 129 if (success == nil) then 130 print(errormsg) 131 end 132 133 end 134} 135 136if not _OPTIONS["dir"] then 137 _OPTIONS["dir"] = "/usr/local/" 138end 139 140_OPTIONS["dir"] = string.gsub(_OPTIONS["dir"] , "\\" , "/") 141 142if not ("/" == _OPTIONS["dir"]:sub(_OPTIONS["dir"]:len())) then 143 _OPTIONS["dir"] = _OPTIONS["dir"] .. "/" 144end 145 146 147function getshortfilename(fullfilename) 148 -- first, replace all backslashes with forward slashes 149 if (type(fullfilename) ~= "string") then 150 return nil 151 end 152 shorter = string.gsub(fullfilename , "\\" , "/") 153 while (true) do 154 start , stop = string.find(shorter , "/") 155 if (start == nil) then break end 156 shorter = string.sub(shorter , stop + 1) 157 end 158 return shorter 159end

While it is mostly straight forward, there are no install targets supported, you have to create them manually (I don't know how other build solutions compare here), and at the time I couldn't figure out a good way to handle filename slashes without converting them to a standard forward or back slash. But configuring a project is pretty easy.

I also took a brief look at Scons once, and it seemed pretty nice too. I still haven't decided on a build system for my library other than a CB project so far. I had a giant makefile for Eagle 4, but it was complex and difficult to maintain and I ended up abandoning it.

bamccaig
Member #7,536
July 2006
avatar

The vast majority of projects are probably still using autotools and/or Makefiles. CMake is used by a tiny minority of projects, and Scons probably even fewer. Premake is pretty much off the map. For the majority of small to medium sized projects Makefiles or Autotools are probably plenty acceptable, and odds are for projects where it's a nightmare to maintain the equivalent CMake or Scons is probably no better.

It sounds like the SCons community accepts that their solution isn't really all that good most of the time:

http://www.scons.org/wiki/SconsVsOtherBuildTools

Similarly, there is no real clear winner in the bunch. Some of them propose to do things better than plain Makefiles, but in practice it probably comes down more to experience with a given tool than the tool itself.

Thomas Fjellstrom
Member #476
June 2000
avatar

if cons was more popular, I'd so use it. Scons was based on it sorta, except cons is perl, and Scons is python (iirc).

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Aaron Bolyard
Member #7,537
July 2006
avatar

I use Premake5 in any C or C++ project that has more than one source file. It's pretty nice. The syntax is miles ahead of CMake, that's for sure.

Oh, and my opinion of Makefiles is that they're an ancient relic and only useful for being the target of a build generator or IDE.

---
ItsyRealm, a quirky 2D/3D RPG where you fight, skill, and explore in a medieval world with horrors unimaginable.
they / them / their - Erin Maus

pkrcel
Member #14,001
February 2012

The syntax is miles ahead of CMake, that's for sure

While I advocate Cmake as a godd tool overall, this can't be denied also, I should have said that in my previous post.

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

SiegeLord
Member #7,827
October 2006
avatar

More than half of Allegro's dependencies use CMake, sometimes alongside autotools. In those projects, the CMake building experience in unimaginably better than the one afforded by autotools.

On GitHub, my searches seem to suggest that CMake is a lot more popular than autotools is. Here are my search strings:

filename:CMakeLists extension:txt path:/ -> 47672 results
filename:configure extension:ac path:/ -> 29101 results
filename:autogen extension:sh path:/ -> 16039 results

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

bamccaig
Member #7,536
July 2006
avatar

Allegedly bootstrap is becoming a semi-popular alternative to autogen.sh, and that yields another 2592 results.

1 11
29101
16039
 2592
=====
47732

Obviously this is a rough estimate (even without bootstrap, which probably yields a few false positives, you still have 45140), but it's still a far cry from being "a lot less popular". And of course this only includes projects that are tracked by GitHub, which is still probably a minority of free software and open source projects (Autotools is pretty much a standard for official GNU projects). It also probably includes many positive matches from both camps that turn out to be nothing more than beginners and intermediates experimenting or starting Monday projects that never take off, not to mention "forks" which are really just clones or collaborators of the same project. You're also excluding pure Makefile projects (not using Autotools), which yields another 321934 gross results for me[1] (plus 2603 for GNUMakefile).

In any case, in my experience cmake is a far cry from being a solution. It may have some pros, but it has some cons too; and overall it isn't the saving grace that we all wish would come. I can't be too hard on it either because I haven't learned to manage it yet myself, but what experiences I have had haven't impressed me yet.

References

  1. On second thought, try your searches a few more times. The numbers are as reliable as Windows 95 Explorer calculating estimated time of completion (literally jumping up and down by hundreds of thousands)... :-/
SiegeLord
Member #7,827
October 2006
avatar

You can't just add autogen.sh and configure.ac together, as most if not all will be overlaps :P. I just provided the two searches as two different canaries of autotools projects. I don't think github search produces very accurate results for files without extensions, so I didn't search for 'makefile' alone. I wouldn't necessarily truly believe that there are only 50000 CMake projects (seems like a tiny fraction of the total number of C/C++ projects even allowing for an occasional Windows-only project) though.

bamccaig said:

And of course this only includes projects that are tracked by GitHub, which is still probably a minority of free software and open source projects

http://readwrite.com/2011/06/02/github-has-passed-sourceforge and that was 3 years ago :P. Every important project I know of has a github mirror too.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

bamccaig
Member #7,536
July 2006
avatar

That is such a bad Web site that it displays nothing without scripting. :-/ Way to choose a good source. ::) In any case, SourceForge has always been terrible. It wasn't the breeding ground of quality software. The occasional decent project exploited its generosity and was oblivious to how terrible they always have been (e.g., Allegro), but most good software was independent or at least elsewhere. For example, I don't think that GNU generally uses any such service (they probably wouldn't trust said third parties to host them securely).

Elias
Member #358
May 2000

Oh, GNU uses things like http://gna.org or http://savannah.gnu.org/ which are much worse than even SourceForge :P

--
"Either help out or stop whining" - Evert

bamccaig
Member #7,536
July 2006
avatar

Savannah doesn't sound so bad. Of course, GNU puts things like freedom above convenience so there's no surprise they'd do that. And I fully support that decision. It doesn't change the fact that SourceForge is and always has been a pile of shit. Apparently untrusted shit if GNU won't touch them!

Chris Katko
Member #1,881
January 2002
avatar

Quote:

Way to choose a good source. ::)

Meanie! :-/

My dad died writing that page. :'(

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

Thomas Fjellstrom
Member #476
June 2000
avatar

bamccaig said:

Savannah doesn't sound so bad. Of course, GNU puts things like freedom above convenience so there's no surprise they'd do that

Excuse for laziness. They could make it nice, but they choose not to.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

bamccaig
Member #7,536
July 2006
avatar

Your interpretation of nice and their interpretation of nice may be different. Several hackers prefer "plain text" HTML in black and white with no fancy formatting, fonts, colors, etc. Just headers, paragraphs, and lists. Pure function without form.

They might also just have limited resources (we know that much is true). They aren't going to ever compete with GitHub or even SourceForge because that isn't their portal's role in life. There's no real point trying.

What exactly are the complaints about Savannah? I don't remember ever using it (aside from maybe downloading/cloning/checking something out from it once or twice).

Go to: