|
Am 29.09.2013 14:06 schröbte steve donovan:
On Sun, Sep 29, 2013 at 12:17 PM, John Hind <john.hind@zen.co.uk> wrote:Installation is a one-off procedure and it is more important that it is reliable and automated than that it is as fast as possible. I'd rather spend 10 minutes staring at a progress bar than half a day trying to debug a makefile!That's a good point. The LuaRocks built-in backend works like how you describe; it directly invokes the configured compiler to build extensions. (People have LR working quite fine with MSVC). The problem is that people usually have a makefile, and so the easiest route to publishing as a LR rock is to use that makefile. It's possible to do reasonably complex builds with the built-in backend, for instance I once got LuaSocket building like that cross-platform, but that's an extra bit of effort.
And that's why I don't get what this discussion is about: Luarocks offers a nice, simple, cross-platform description of how a package is built, and still lets the developer choose his/her build tool of choice (or none at all with the `builtin` build type, which is very convenient for the user). Some modules require luarocks to build, so what? The situation is hardly different with other scripting languages: E.g. there's `ExtUtils::MakeMaker` and `Makefile.PL` for Perl, and `Distutils` and `setup.py` for Python. Plus a lot of packages already provide rockspecs. 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). Maybe we could also provide a standalone script (or module) that is easier to install than luarocks (maybe some amalgamation of the necessary luarocks source files packaged as a single standalone module/script), but that's as far as I would go. So our efforts should be directed at making luarocks better instead of creating yet another build tool ...
Everything IMHO, of course. Philipp[*]: My suggestion would be `lua_path` and `lua_cpath` (and `lua_bin` for scripts). Then the installation instructions for a manual install would be:
luarocks manual[**] some.rockspec mv lua_path/* some-dir-in-LUA_PATH/ mv lua_cpath/* some-dir-in-LUA_CPATH/ mv lua_bin/* some-dir-in-your-PATH [**]: Subcommand name still subject to change ;-)