[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Wishlists and Modules (was [ANN] libmc)
- From: steve donovan <steve.j.donovan@...>
- Date: Fri, 4 Sep 2009 08:18:24 +0200
On Fri, Sep 4, 2009 at 3:17 AM, Doug
Rogers<doug.rogers@elbitsystems-us.com> wrote:
> bin2c does indeed work for simple files; I've used that technique many
> times. The tendency these days, though, is to do more and more in Lua and
> push only the essentials into C. That's a good thing in many ways. But it
> also makes it harder to retarget each library as an all-in-one, statically
> compiled, sans file system binary. Each library has to be combed over to
> find which Lua files in the hierarchy are truly part of the install base and
> then the proper load order has to be determined. I'm not convinced (yet)
> that this can be an automatic process.
Maybe not fully automatic, but most of the shlepp work can be done by
parsing the files (various options exist) and finding out the actual
dependencies. A semi-automatic option would be best, like the Linux
kernel configuration menus. You would choose what libraries you want
to embed, and it would generate the appropriate build.
On the subject of using LuaRocks, I agree with David that it can be
made to do the job, with some tweaking so it builds static libraries.
Treat it as a build tool, and copy the resulting libraries to a more
sensible place, no require 'luarocks.require' necessary. The version
of Lua for Linux I'm working on does this. This is soon going to be
moot, because LuaRocks 2.0 is going to use the 'canonical' paths.
Automation is on my mind currently, thinking about a 'wizard' for
generating rockspecs given a source archive. The hard bit tends to be
the impenetrable fog which is the average makefile. Unfortunately
this excellent piece of late 70s technology is not a good way to
express build rules in a cross-platform way.
steve d.