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.

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...

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. :/

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 :

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.

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).

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

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.

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).

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!

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