[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] Lake - another Lua-based Build Tool
- From: steve donovan <steve.j.donovan@...>
- Date: Thu, 14 Oct 2010 14:37:21 +0200
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 ;)
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)