Re: Make+Lua = winner (Re: Prime Mover v0.1)

["Ken Smith" <kgsmith@...>]

$(lua) doesn't do fork/exec, it simply executes the Lua program in the current process.  If you do $(shell) a lot or in a loop, you'll notice the performance impact of the fork/exec system calls.

  Ken

On 10/17/06, Asko Kauppi <askok@dnainternet.net> wrote:

What is the benefit that $(lua ...) would bring, especially since a $
(shell lua ...) can be defined to a macro?


Ken Smith kirjoitti 17.10.2006 kello 0.09:

> I recently posted a patch to the GNU make mailing list that hasn't
> gotten a lot of attention yet.
>
>  http://lists.gnu.org/archive/html/help-make/2006-10/msg00018.html
>
> It adds $(lua ...) to make so you can execute lua programs similarly
> to the way you can execute shell commands with $(shell ...).  I think
> this may obviate the need for Guile support which has been on the
> radar for several years.
>
> If any of you think this is a great thing for make, please make some
> noise at help-make@gnu.org so we can possibly get the maintainers to
> accept it into the official distribution for the next release.
>
> I'm including the original attachments as the linked mail archive
> munges the filenames when I try to download them.
>
>  Ken Smith
>
> On 10/16/06, Asko Kauppi <askok@dnainternet.net> wrote:
>>
>> ...which brought to my mind, that Hamster does .h dependencies
>> automatically.
>>
>> I agree with you; having been both a Make what-the-... and, nowadays
>> a huge fan (to the extent that I get mocked at work about that) of
>> it.  It does rule, and I'm suggesting it to use outside of the
>> building processes as well. Any dependencies, that's Make.
>>
>> To the point?  I'd like to take part if someone wants to start a "Lua
>> macros for make" project. It'd basically be a set of Makefiles (for
>> inclusion) that define usable features, using Lua.  The use would be
>> to come along without sed, awk, grep and other such Unix candies,
>> allowing the Make+Lua+macros approach to run on Windows (ehem!) based
>> machines as well.
>>
>> I think LuaRocks will need this; and I'm going to be there to help
>> build it. But the scope of usability would be wider.
>>
>> -asko
>>
>>
>> Sam Roberts kirjoitti 16.10.2006 kello 21.26:
>>
>> > On Fri, Oct 13, 2006 at 06:44:58PM -0700, Wesley Smith wrote:
>> >> I can't tell you how much I agree you here.  Everytime I've
>> tried to
>> >> use make to build a project of any size that uses
>> subdirectories, it
>> >> has been a nightmare of looking at GNU's make documentation and
>> >> wondering who on earth made such an esoteric beast.  I wonder
>> if the
>> >
>> > make doesn't care what directory your files are in, you haven't
>> > figured
>> > out how to use the tool yet if that is causing you trouble.
>> >
>> > People have trouble with make because they attempt to use it as an
>> > imperative language. Its not, its a rules-based language (akin to
>> > logic
>> > languages like Prolog) wherein you state the conditions that
>> must hold
>> > for a particular goal ("target") to be satisfied. I think its
>> the only
>> > language of that type that is commonly used.
>> >
>> > The other thing that people don't get about make is its a unix
>> > tool. It
>> > does ONE thing well, evaluating dependency rules to determine
>> how to
>> > achieve goals. The rules themselves are usually built
>> statically, in a
>> > language other than make, i.e., you have to mix make with other
>> tools
>> > for a complete build system.  In particular, dependency rules
>> > should be
>> > built by a tool that knows as much as possible about C code... like
>> > a C compiler:
>> >
>> >       http://make.paulandlesley.org/autodep.html
>> >
>> > Cheers,
>> > Sam
>> >
>>
>>
>> <GNUmakefile>
>> <make-3.81-lua-5.1.1-function.c.patch>
>> <make-3.81-lua-5.1.1-Makefile-Gentoo-Linux-2.6-ppc.patch>
>> < make-3.81-lua-5.1.1-Makefile.patch>