 |
lua-l archive |
|
|
||
|
Am 01.10.2013 15:08 schröbte Peter Drahoš:
On 1 Oct, 2013, at 11:18 , Philipp Janda <siffiejoe@gmx.net> wrote:Am 01.10.2013 09:21 schröbte steve donovan:On Tue, Oct 1, 2013 at 8:39 AM, Philipp Janda <siffiejoe@gmx.net> wrote: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.That sounds very doable. Key concept is 'portable and easy'. Especially if we restrict ourselves to the built-in backend - unfortunately, there are all these damn makefiles (which Peter rightly identifies as useless for cross-platform)LuaRocks has platform-overrides, so the existence of a makefile doesn't necessarily mean that the rock is non-portable. E.g. I have a rockspec that uses `builtin` on Windows, and a makefile on Unix (because I need the output of `apr-config` there). If you bind a library that works for Unix only, there is no reason not to use Make/Autotools in your rockspec.The platform overrides are nice in theory, in practice if the author of the rockspec does not provide it .. no one will.
Did you mean rockspec author or binding author here? In the first case that's pretty obvious. You could of course download a rockspec yourself and fix the build instructions (which is hard because usually if you do this you have no way of executing the original build script to observe what it does), but those modified rockspecs usually aren't published. If you meant binding author: Then that's exactly my point. It needs a lot of energy to enhance/modify the build scripts and not just take what's already there. But maybe that's LuaRocks' curse, because you *can* just use the build script that's already there ...
There may be no reasons not to use Autotools until you actually use it, after that there are many reasons not to use it.
I meant the following: If you already use Autotools for your bindings, and the library you bind is for Unix only, there is no reason not to use the generated configure scripts and makefiles in your rockspec, because everything that is needed by those is usually installed on a Unix system anyway.
whereas I suspect the majority of them could be replaced by built-in rules. However, that's a lot of rockspecs to hijack - remember they all have maintainers.That's the same type of problem, the LuaDist guys are facing: The original binding creator has chosen a certain build tool that works for his/her choice of platforms, and the rockspec maintainer now can either use the (possibly well-tested) build script of the binding author, or port this build script to a more portable format (`builtin`-rockspec or CMake file). Bindings are usually much smaller than the libraries they bind, so if we can't get it right with `builtin`-rockspecs, you can probably imagine why I don't have much faith in an approach like LuaDist …The original binding creator usually does not consider distribution to be an issue or simply does not care to support your particular setup. Therefore the default build systems often fail to integrate into a distribution system well and you need to modify the build anyway.
Yes, that's why we have separate rockspec maintainers for LuaRocks (and CMake file maintainers for LuaDist).
Additionally LuaRocks faces the problem of pulling in too many dependencies because it has to support multitude of tools and build systems to actually install all the modules.
The dependencies for LuaRocks are not that bad: No external dependencies for `builtin` obviously (other than a compiler). Everything is there on Unix (and maybe Cygwin) for `make` (and `command + autotools`), but it won't work at all on Windows even if you do have a make and/or a bourne shell. For generic `command` build sections it obviously depends on the actual commands that are run (the shell itself is available of course). So the only dependency that is missing by default is CMake.
> LuaDist just needs CMake + Compiler and even that is only required for building from source.
Doesn't CMake generate Makefiles/Visual Studio Solution files, etc. any more? It did when I last looked, but I admit that was ages ago. If you say that it doesn't I will have another look (the MS Project/Solution files scared me away the first time).
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!I don't hold out much hope, really. I personally find it very useful, of course, but it's unlkely to get any traction. But we have the output of these tools...a little installer is not that complicated.There hasn't been much progress in general adoption of a standard build tool since Make (and that one relies heavily on external programs), so I don't hold my breath either. That's why I like the "meta-build-tool" approach of LuaRocks.Yeah, rolling your own is always great .. now there are +1 more standards to choose from and to support.Scaling of LuaDist? Well, through heroic effort Peter has grown it (much of his work is reverse-engineering the build rules and turning them into CMake files).That is no small feat for sure, but heroism is a limited resource. Sooner or later every project will have to work with an "average" maintainer …Its not really an issue with the CMake approach as its reusable outside of Lua distributions, most of the forks of my libraries on github are actually for different purposes than building lua dependencies. I don’t really see a place for LuaRocks to be used as a generic build tool outside of its context. However there are other people rewriting existing libraries to be built using CMake for the same reasons as I did, mostly they are just a google away.
And maybe that will be enough, and maybe those forks won't fall behind when the person who forked loses interest in using the library. My crystal ball has been wrong before, and in this case I actually would be very happy about it ...
pd
Philipp