lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


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 ;-)