 |
lua-l archive |
|
|
||
|
Am 30.09.2013 10:00 schröbte steve donovan:
On Sun, Sep 29, 2013 at 6:11 PM, Philipp Janda <siffiejoe@gmx.net> wrote:I can understand that some people don't want to install the resulting files in the rocks tree, but that can be achieved simply with a new luarocks subcommand (something like `luarocks make` which doesn't check/download dependencies and moves the resulting files into a subdirectory of the source directory[*] instead of installing into the rocks tree).A good idea.
Apparently I'm not the first one to think it: See Hishams message about `luarocks --nodeps --pack-binary-rock build` (or better `make`), but the current implementation unfortunately creates a temporary rocks tree and manifest and therefore basically requires every existing luarocks submodule (and some unnecessary external tools).
That's a big job, and feels like a fragmenting move .... better to use a tool specialized in building (I naturally like Lake for this ;)) and a tool specialized for installing.
LuaRocks already supports some common specialized build tools. We don't need another one. What we need (IMHO) is a script (as portable and easy to install as possible) that uses the information in a rockspec and the meta build tool embedded in LuaRocks, and spits out a directory hierarchy of dlls and lua files suitable for manual installation/embedding/packaging. If you can convince most Lua developers to use Lake instead of autotools, make, cmake, shell scripts, and/or <insert obscure tool here>: Bravo, that will make things easier! But until then we will have to deal with a bunch of specialized build tools, and LuaRocks does a decent job at it.
Ordinary users would be more happy if all the common modules were already built as binaries for their platform, applies to both Windows and OS X I think. Then LR is a good delivery vehicle. LuaDist has an edge here, since it's an ambitious 'build-the-world' system and binaries come directly out of the process, which is why we would recommend the LD batteries for no-fuss installations. The two systems aren't necessarily in competition and could (and should) be harmonized at some point.
I think we agree on the basics, but come to different conclusions: LuaDist makes it easy to provide a working binary base distribution because it also compiles/delivers external dependencies, LuaRocks is for compiling/installing stuff yourself, because it doesn't have a dependency on a particular build tool like cmake (although the rockspec itself may have), and you don't have to port the libraries' native build scripts to cmake. I'm not sure if the LuaDist approach will scale beyond a certain size, because you need to create and maintain build scripts for a lot of third-party libraries ...
steve d.
Philipp