lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 1 April 2013 18:28, Peter Drahoš <> wrote:
> On Mon, Apr 1, 2013 at 7:21 PM, Thijs Schreijer <> wrote:
>>> > See
>>> >
>>> The author did not follow the correct instructions for installing
>>> prerequisites[1], in short having sh.exe in your path is a BAD idea for
>>> various reasons. The install instructions for LuaDist[2] should be easy
>>> enough if you want to build from source. You can also use the binary
>>> downloads from[3].
>> Peter is right, I did have that. But the quote above, at all, is a remark that fits with a unix-type-of-guy, even on a windows system (no offence to Peter). I happen to be a windows-type-of-guy on a windows system, so dependencies like that remember me of the DOS days.
>> There is a new effort trying to get stuff working out of the box, based on LuaDist, probably a gui and then some. That looks great, but isn't there yet. LuaDist bundles LuaRocks, but it doesn't work (steve already filed an issue for the missing config file), that was my main reason to drop LuaDist for now and switch back to LuaRocks again.
> No offense taken, we want the same thing. Just pointing out that
> LuaRocks is not the solution to the situation on Windows. But I agree,
> LuaDist is not there yet, hence the initiative on the luaforwindows
> mailing list but It is usable as it is now.
>> I found myself in the same situation as the OP, tired of LfW with outdated modules, non-functional/upgradeable LuaRocks, based on an old runtime. So I set out to do it from scratch and the post mentioned are my findings so far.
>> Any way, Lua on Windows is a PITA. Probably a short coming on my end, not being used to commandlines, makefiles, or stated otherwise a lazy, ignorant windows user (that even considers Visual Studio to be a fantastic product).
> It is, but it has excellent binary compatibility for what its worth.
>>> Its also worth noting that LuaRocks will not install any external
>>> libraries so the selection of packages you can install on Windows is
>>> limited.
>> Didn't get that one... what do you mean with "external libraries". Do you mean in some cases it will build the Lua binding for a library, but not the underlying library itself?
>> Doesn't LuaDist only build the packages it has in its repo?
> To make things clear. LuaRocks is a binding manager, it is
> specifically designed to deliver Lua bindings some of which point to
> _external_ libraries which are taken from the host operating system
> package manager. Since Windows does not have one it is very limited on
> the platform as you need to build and supply the libraries yourself.
> This situation is generally recognized as "dll hell" because you will
> end up using libraries from various sources which may be incompatible.

Not contradicting the essence of what Peter said, but just to make the
terminology clear: LuaRocks does not manage only "bindings" (ie,
bridges to libraries written in other languages). It is a package
manager *for Lua modules*. Some of these modules are bindings to
external libraries (and Peter's description in this case is correct).
Some other Lua modules are written in pure Lua, pure C or a mix of
both, and may contain dependencies to other Lua modules. In the case
of dependencies between Lua modules, LuaRocks certainly behaves as a
package manager: it follows the dependency tree and installs them for
you. LuaRocks is software in the same category as npm for JavaScript,
RubyGems for Ruby, Cabal for Haskell, pip for Python, and so on.

I guess what he meant is that LuaDist is a general-purpose package
manager, which comes in handy in Windows platforms because it carries
a number of libraries which are useful as dependencies for Lua

-- Hisham