Re: Prime Mover v0.1

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Asko Kauppi

Made sure it works:

<<
AAA= $(shell lua -e "print 'aaa'")
XXX= $(shell lua -e "print 'var1'")

all:
	@echo $(AAA)
	@echo $(XXX:var1=hey)
	@echo $(XXX:var1=there!)
<<

% make -f koe.mk
aaa
hey
there!


Asko Kauppi kirjoitti 17.10.2006 kello 22.49:


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 [hidden email] 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 <[hidden email]> 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>



Reply | Threaded
Open this post in threaded view
|

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

Ken Smith-2
In reply to this post by Asko Kauppi
$(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 <[hidden email]> 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 [hidden email] 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 <[hidden email]> 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>


Reply | Threaded
Open this post in threaded view
|

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

Ken Smith-2
Sorry for the double reply.  Another issue with $(shell lua ...) is that you have to be very careful about dollar sign ($) expansion.  GNU make expands them, the shell expands them, and they may be valid characters in your Lua program.  $(lua) avoids the shell's contribution to this difficulty.

  Ken

On 10/17/06, Ken Smith <[hidden email]> wrote:
$(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 <[hidden email]> 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 [hidden email] 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 <[hidden email]> 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>



Reply | Threaded
Open this post in threaded view
|

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

Ken Smith-2
$(lua) uses a single lua_State so you can define functions or set variables in one include file and use them in another.  The following is identical to your example when running with my patch.

<<
AAA= $(lua printmake('aaa'))
XXX= $(lua printmake(var1))

all:
        @echo $(AAA)
        @echo $(lua var1='hey')$(XXX)
        @echo $(lua var1='there!')$(XXX)
<<

If you run make on these files under strace, you can see there are fewer fork/execs.  I understand this is a trivial example, but you could save further on fork/exec's by using $(info) outside the rule instead of @echo inside the rule.

  Ken


On 10/17/06, Ken Smith <[hidden email]> wrote:
Sorry for the double reply.  Another issue with $(shell lua ...) is that you have to be very careful about dollar sign ($) expansion.  GNU make expands them, the shell expands them, and they may be valid characters in your Lua program.  $(lua) avoids the shell's contribution to this difficulty.

  Ken


On 10/17/06, Ken Smith <[hidden email]> wrote:
$(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 <[hidden email]> 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 [hidden email] 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 <[hidden email]> 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>




12