On 1/22/2012 2:47 AM, Konstantin Tokarev wrote: > > 22.01.2012, 12:07, "Jason McKesson"<korv...@gmail.com>: >> On 1/21/2012 8:59 AM, Konstantin Tokarev wrote: >> >>> 21.01.2012, 19:00, "Gour"<g...@atmarama.net>: >>>> On Sat, 21 Jan 2012 08:40:16 -0500 >>>> Jason Perkins >>>> <star...@industriousone.com> wrote: >>>>> They solve different problems. Lake builds your software, like rake >>>>> or make. Premake generates the input files for tools that build your >>>>> software. >>>> Thank you. >>>> >>>> Now it's clear we want/need premake. ;) >>> However, it would be great if we had some form of "build tasks" defined >>> in Lua >>> in Premake. Some common operations (e.g., copying/renaming/symlinking >>> files, >>> creating directories) cannot be defined in portable manner using only >>> underlying >>> build tool. I hope that my patch allowing to define chains of actions >>> linked by >>> dependencies [1] can improve this situation, however solution of Lake may >>> appear to be more powerful. >>> >>> There are a few other things that Lake does better: >>> >>> 1. It uses LuaFileSystem instead of custom code for file operations. >>> 2. It's more oriented on being usable as Lua module >>> 3. It includes some built-in support for pkg-config (we doesn't do it >>> beyond >>> generic os.outputof()) >>> >>> [1] >>> http://sourceforge.net/tracker/?func=detail&aid=3465239&group_id=71616&atid=531880 >> Premake exists to be able to build build files for existing build >> systems. It should not be used to actually build the project or do any >> kind of pre-processing build setup work. > I don't get this point. What do you propose for build setup? Autoconf from > Stone Age? What do you mean by "build setup"? Selecting particular attributes of builds (which libraries to include, etc) are perfectly possible in Premake. But pkg-config stuff is too platform-specific for a cross-platform tool like Premake.
What I mean is doing things like executing ANT/NANT-style tasks. Anything that would be called a "build task" is something Premake should not be doing. Premake shouldn't be creating files, renaming things, moving directories around. Premake scripts should be searching for stuff, and setting up a build system that will use that stuff. Creating things, moving stuff around, etc, should be done by the output build files, not by Premake. A Makefile can do all of that stuff just fine. >> Using LFS means requiring LFS, which means having a dependency. Which >> means that it's not a simple "download-and-go" system, but instead >> requires installation. That's bad. > I don't get this too. > 1. LFS is not something big and it doesn't have external dependencies. It can > be > easily included into Premake, replacing custom code. > 2. Ignoring well-tested and widely used 3rd party code is just NIH syndrome. 1. LFS is still extra. It's external to Premake. You now have a premake4.exe and a lfs.dll to worry about, instead of a single file you can download and use. 2. NIH is perfectly valid, depending on the circumstances. In the case of Premake, it makes sense. Premake implements things that LFS doesn't come close to. And Premake doesn't implement things like creating symlinks, etc, because those are not things Premake scripts ought to be doing. ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Premake-users mailing list Premake-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/premake-users
