On Fri, Apr 5, 2013 at 10:55 AM, Thijs Schreijer <th...@thijsschreijer.nl>wrote:
>
> Then the LuaRocks installer would have to be changed. It now looks
> explicitly for "lua5.1.lib" in the \bin\ and \lib\ directories. So it would
> have to look for multiple files; "lua5.1.lib liblua.dll lua51.dll" (any
> others?) and then depending on what is found, should write the variable
> section into the "config.lua" file.
>
I think that would be the idea, yes.
>
> When compiling with MinGW this is the correct default imo. If you compile
> against msvcr80, you would probably use the Microsoft compiler anyway.
>
It depends - if you are using the built-in Lua or LfW, then -lmscr80 is
appropriate for mingw as well. Things will get much clearer once we move
off this runtime, and have precompiled rocks for straight mingw. Once we
have about a dozen of the main libs precompiled, then users will mostly not
need a compiler.
For the 'Kepler Desktop' we would be using the batteries compiled by
LuaDist, which also has luarocks. However, the missing bridge is an LR
manifest for the existing packages in the batteries, so LR knows it doesn't
have to install lfs, luasocket, etc. LR remains the best way to get cutting
edge Lua packages (especially with self-publishing on rocks.moonscript.org)
but it's somewhat weak at the cross-platform compile thing. Combining LD
and LR is complementary for a Lua distribution!
steve d.
------------------------------------------------------------------------------
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire
the most talented Cisco Certified professionals. Visit the
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
_______________________________________________
Luarocks-developers mailing list
Luarocks-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/luarocks-developers
