Re: Lua Distributions and Package Management

[Peter Drahoš <drahosp@...>]

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. In LuaDist you write once and build everywhere. Yes, it is harder to create CMake files for external libraries but for plain lua files and libraries its dead easy and the “builtin” type rockspecs can even be used directly if need be.

There may be no reasons not to use Autotools until you actually use it, after that there are many reasons not to use it.

> 
>> 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. 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. LuaDist just needs CMake + Compiler and even that is only required for building from source.

> 
>> 
>>> 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.

pd