Re: Lua for Windows: Why not use LuaRocks instead?

[Hisham <hisham.hm@...>]

On Fri, Sep 12, 2008 at 12:34 PM, Andrew Wilson <agrwagrw@gmail.com> wrote:
> Matt
>
> Original motivation of LfW was for single .exe  installer to allow
> people to easily try out Lua.  Linux mindset is build your own.
> Windows mindset is click to install, so LfW is tuned to click to
> install. LfW is more aimed at programmers interested in trying Lua as
> a standalone scripting language.
>
> LuaRocks is the right solution for building from source, but requires
> more tools (compilers,linkers), setup (libs,headers)  & runtime
> compatibilities to use.
>
> A goal for LfW is to work with LuaRocks. We're still trying to figure
> that all out.

To complement this answer, LuaRocks is able to work with binary
packages. A LuaRocks installation pre-configured to use a rocks server
that provides only binary packages, for example, wouldn't ever require
the user to have a compiler toolchain installed. Of course, every
dependency to every rock needs to be there in the rocks server.

The current situation is that at the main rocks server we provide
some, but not many, binary rocks for Win32 right now. Basically we
provide the ones developed by the Kepler project, and their
dependencies. The binary rocks that are there are compiled with
VS2005, which was the (please someone correct me if I'm wrong)
recommended toolchain by LuaBinaries. Of note is the fact that we
don't have yet binary rocks for all modules provided by LfW (as a
matter of fact, we don't even have rockspecs for them all yet).

Another issue is external dependencies: for example, if you install
the luasql-mysql rock, you need to have MySQL already installed
(installing MySQL is of course beyond the scope of LuaRocks). On Unix
systems they are usually provided by distribution packages; on Windows
the user needs to get the appropriate installer. LuaRocks does it best
to inform the user about this, and that's about all it can do. For
some cases (SQLite?), linking dependencies statically to the binary
module could be a good option, and that could avoid dependency
troubles, but it's still an issue to be aware of in the general case.

-- Hisham