Re: roadmap for Lua

["Hisham Muhammad" <hisham.hm@...>]

On Jan 5, 2008 1:39 AM, Wesley Smith <wesley.hoke@gmail.com> wrote:
> > At this point, the rockspec format (rules files used by LuaRocks to
> > build/install modules) is still evolving, mostly to accomodate the
> > needs of various modules: some have Makefiles, some don't, some
> > makefiles don't have an "install" rule, some makefiles hardcode
> > "-shared" to build libraries (which doesn't work on, e.g., OSX, while
> > the actual code usually builds fine), etc. Currently, I'm making
> > LuaRocks jump through these hoops, but hopefully over time module
> > authors will take LuaRocks into consideration and will write more
> > rocks-friendly makefiles (I told you I dream big!).
>
> What about using Premake (http://premake.sourceforge.net/about) a Lua
> based and quite flexible Makefile/autotools replacement.  It can
> generate VS projects among other things.

Premake looks interesting, but it's not up to me to choose, as it's a
matter of what build tool module authors decide to use. LuaRocks
currently supports using make and cmake (cmake support being
contributed by the folks of the LuaDist project, which uses it), as
well as "module", a special build mode in which Rocks calls the
compiler itself, playing the role of the build tool (which works well
for pure-Lua and simple C modules). I can happily add support for
other build tools such as premake, autotools, etc.; the thing is I
haven't found modules out there using them, so I had no motivation or
test cases.

Actually, I did find some modules using autotools such as IIRC bitlib,
but the "module" build mode worked just fine for that, allowing me to
just ignore the configure scripts. In some other rocks using 'make' I
did ignore the provided makefile and went to use "module", because
that was more portable than the provided makefile. It's not my intent
to redo the work the makefiles written by module authors are doing (I
always use them when I can), but sometimes it's faster just to tell
LuaRocks which .c files to compile than to convince the module's
makefile to accept a linking flag or a configurable location of the
Lua libraries. But if the rules files written by module authors (be it
autoconf scripts, premake files, cmake lists, plain makefiles, etc.)
are usable and flexible (ie, allow for different linking flags,
installation locations for both the package and its dependencies,
including Lua itself) without having to be hand-edited, it's best to
use them.

> It's compiled as an app but
> I bet it could easily be made into a module for distribution with
> Rocks and would save you a good chunk of dev time supporting multiple
> different methods of making projects.

The dev time spent to support each build tool is a one-time hit. And
the number of different build tools is small, while the number of Lua
modules is much larger and grows faster. So, as a whole, even
supporting, say, 10 different build tools in LuaRocks would be less
work than converting the build rules of every Lua module to premake.

Also, allowing devs to do things their own way rather than convincing
everyone to do the same seems to be more in line with the Lua spirit.
LuaRocks aims to be the minimum amount of "central coordination" so we
can get an efficient community of shared modules. Even its more tricky
parts are part of this goal, such as the require() tweaks to allow
different versions of a module to be installed simultaneously in a
system -- in this specific case, the idea is not to have to push every
module author to upgrade their code to the same version of a module in
order to make it to the repository, and not to force into choosing
between the version of X that works with Y or the one that works with
Z. That's one point where extra complexity was added to the tool to
reduce the complexity in community interactions.

-- Hisham