Re: [ANN] Lake - another Lua-based Build Tool

[steve donovan <steve.j.donovan@...>]

On Thu, Oct 14, 2010 at 2:00 PM, Philippe Lhoste <PhiLho@gmx.net> wrote:
> I suggest to update the wiki page to point to Lake.
> Googling for "lua build tool", the page on Bou was the first listed, and
> seeing your signature at the end, I remembered this thread...

Thanks, I have put in a link at the top; I may also create LuaLake as
a wiki page for discussion (less complicated than github wikis)

> Still, from a quick look, it seems to be natively aimed at C[++]
> compilation, no?

That's what it knows well.  It knows a fair number of things, but they
are not well organized ;)  In an ideal world there would be separate
modules for separate compilers.

I did some experiments with Java building, which I'll revisit - it
seemed to work cleanly and did not take much extra code. But then I
realized that Lake was getting fat and overconfident, so the Java
stuff will be brought in sensibly with "require 'lake.java'".

> I will lazily expose my goal here, as discussing it might improve interest
> in Lake... ;-)
> Ant, I prefer to avoid. Tried it and got an XML allergy

Don't like it either. I really think there are limits to the
declarative-build approach.  And it feels heavyweight, although this
is the JVM we are talking about ;)

steve d.

PS. Tried building lfs.c using

d:\libs\lfs> lake -lua lfs.c
gcc -c -O1 -I"C:/Program Files/Lua/5.1/include"  -MMD  lfs.c
gcc lfs.o lfs.def  -L"C:/Program Files/Lua/5.1/lib"  -llua5.1
-lmsvcr80  -shared -o lfs.dll

It's trying to be helpful (this is LfW) so I hope it doesn't always
try to link against the VC2005 runtime ;)

(BTW, mingw gcc chokes on the 'VERSION' field in the .def file. Take
it out and things work)