On 3/15/2012 2:23 AM, Konstantin Tokarev wrote: > > 15.03.2012, 09:11, "Jason McKesson"<korv...@gmail.com>: >> It's a *build system*, not an application; it's not that complicated. >> And if your build system is so big and complex that you can lose track >> of what globals, add-ons, and so forth you've included, something has >> gone wrong somewhere. > Premake is an application, and it's already complex. Add-ons are supposed > to extend *Premake* out-of-the-box capabilities and may be written by > 3rd parties. > >> Remember: build rules are supposed to be the exception, not the default. > For my use cases they will be default (e.g., Qt support requires at least 6 > build > rules). Also remember that build rules can be used to implement support for > programming languages other than C/C++, code generators, and preprocessors. Premake is, generally speaking, for being able to have a cross-platform build system that works the same everywhere. That way, I can develop using Visual Studio, but you could use Make, and someone else can use Code::Blocks, etc. And the source of the build is a single, simple format.
Build rules basically throw away any hope of platform neutrality. You're effectively *relying* on certain things not only existing on the user's machine, but them being in certain places (even if it's just the search path). Build rules are always platform-specific. In some cases, they can be build-tool-specific. It's nice to have the functionality; don't get me wrong. But if they are the default case for you, then either Premake or Qt is doing something wrong. If they're going to be the default, then what's the difference between Premake and a Lua file? ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Premake-users mailing list Premake-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/premake-users
