On Tue, Mar 22, 2011 at 6:57 PM, Peter Drahoš <[email protected]> wrote: > Hello list, > I'm integrating LuaRocks into LuaDist[1] and since I last worked on it > things have changed considerably. I'm not sure anymore what dependencies are > needed for what platforms as some have multiple alternatives (wget vs curl). > I have following questions:
Let's go! > * What minimum requirements and dependencies does LuaRocks need on Windows > systems ? > * What can I leave out if Lua modules such as luafilesystem, luasocket, > lua-md5, luasec etc. are available ? I've been trying to gradually reduce dependency on third-party binaries, both on Windows and Unix. The default Windows zip still ships with UnxUtils, but on LfW it is supposed to work with the Lua modules (luasocket, etc.). Looking at the code, I believe the only third-party binary you still need on Windows if you install the Lua modules (luasocket, luasec, lfs, md5) is 7z.exe. > * The same on Unix systems ? In Unix, the equivalent setup uses tar, gunzip, bunzip2, unzip, plus the luaposix module. This is for LuaRocks as a deployment tool only (for packing/unpacking and installing pure-Lua and binary rocks). For using it as a build tool, of course, then you need compilers. For automated repository management (the "luarocks-admin add" command), you need rsync, sftp, ftp and/or curl (depending on your server's protocol abilities). > * Are there any other differences between the unix and windows besides > different "fs" behavior I should know about ? When shipping entries to the bin/ directory, Unix and Windows use their own approaches to make the bin-wrappers. But I think you don't need to worry much about these. We should make them optional in LuaRocks and let the more complete environments such as LfW make their own call on how they want to solve this problem. > * I see commented out code in the install.bat for MinGW .. is it fully > supported ? > * What about MinGW64[2] from the TDM distribution ? Fabio or someone else may know more about the status of mingw and the Windows side. I've never touched this part. > * Is it possible to use CMake as "builtin" platform or generate a "make" > script instead of direct execute calls to compilers as I see in builtin.lua > ? Right now, the "builtin" mode works by calling the compilers itself. CMake is only called in the "cmake" mode. It would be an interesting idea to add a alternative "CMakefile-generator"-based backend for the "builtin" mode as well. This would provide portability to platforms which are not covered by the current "builtin" implementation at the expense of the CMake dependency for those platforms (which is infinitely better than not being supported at all). Speaking of build modes, I know you're not a fan of the "make" mode and I'm not either -- this was added early on in order to reduce friction with developers (I always like to stress that a project like this needs collaboration from module authors) and to reuse earlier work done for the Kepler packages. Nowadays it is rare to see rockspecs submitted with the "make" mode. The "builtin" mode is pretty popular (as I expected it would be). LuaRocks does not intend to be a full-featured build tool, but being able to quickly handle the trivial cases with zero additional dependencies on Linux boxes has its appeal. I'd be happy to recommend "builtin" for the simple modules and the "cmake" backend for the scary stuff (IUP, etc.) and non-Lua libraries. 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. -- Hisham _______________________________________________ Luarocks-developers mailing list [email protected] http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
