On Wed, Mar 23, 2011 at 4:06 AM, Hisham <[email protected]> wrote: > ... > I don't know exactly what path you have in mind for integrating the > use of LuaRocks and LuaDist (making the "cmake" mode hook into LuaDist > when available; making a "luadist" mode so that LR delegates the build > part to the luadist tool; building .rock files with LD and just > deploying them with LR; something else entirely). I don't have any > opinions at this point on what direction would be best. I gave LD a > spin, took a look at its (nice and lean) architecture, but haven't > been able to allocate time for closer investigation yet. This should > change a few weeks from now, but in the mean time I'm happy to assist > any way I can. > I integrated it with LuaDist the best way I could at the moment[1] (works on OSX and Linux). I have the following issues on Windows and Cygwin:
- luarocks.config has rather limited influence. It does override some of the defaults in luarocks.cfg but not for all platforms. It does not allow to set 3rd party utilities such as compression tools, 7zip is hardcoded on windows. I would expect luarocks.config to to be able to override all defaults and settings, even compiler commands and flags (I could auto-configure these from CMake). For example on Cygwin it hardlinks to -llua and ignores LUA_LIB and LUA_SUFFIX. - Path handling. One of the reasons I decided to not use LuaRocks before. It inconsistently uses windows and unix paths, has problems determining what paths are full paths from relative paths. Additionally it has problems with path separators. For example on Windows I get: Failed unpacking rock file: C:\work\Repository/C:\Users\AppData\... - Too many dependencies. I get that it tries to rely on whatever is available to get the job done but in the end it has just too many points of failure. This also results in rather large package thats hard to maintain, for example the luadist utility has about quarter of the code size with heavily documented code. It provides comparable functionality and only uses unzip and cmake. I can deal with most of these issues by modifying LuaRocks to fit into LuaDist but I think it would be better for both projects to converge. I do not plan to develop the "luadist" install utility further and would like to concentrate on providing working packages and portability instead. I can see LuaRocks filling that spot but not in its current state. My recommendations for the 3.0 release would be: - Use only Lua dependencies (lfs, luasocket, md5.. ), make 3rd party tools (svn, git, 7z) entirely optional. The install can be bootstrapped and auto-configured using LuaDist. - Do not reinvent the wheel and use 1-2 well tested (preferably portable) build approaches, eg. builtin, cmake. Support for other approaches should be discouraged/removed. - Rewrite path handling entirely. Do not assume components are installed statically, add prefix capability for all paths used. - All defaults should be configurable, not only some aspects as is the case now. - Reduce code size, remove obsolete functionality, try to consistently handle most systems with the same approach. - Provide an API for use from Lua (good for GUIs and Automation) - Reconsider removing support for "rockspec" installation, instead use "rock" only packages, the former causes fragmentation and download problems. Please do not read this as criticism, I really do want LuaRocks to be better and think these problems need to be addressed. What better time than now ? pd [1] https://github.com/LuaDist/luarocks/commit/e0df468ecf79763e4328649ce9ba5beb629e0181
_______________________________________________ Luarocks-developers mailing list [email protected] http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
