lua-users home
lua-l archive

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

On Wed, Mar 5, 2008 at 12:55 PM, David Girault
<> wrote:
>  > * I left out the $(DESTDIR) changes because they were spread over
>  > every subproject -- it would be simpler to centralize them in the root
>  > makefile, which already controls the install dirs given to each app
>  > (also, each subproject is a separate CVS repo with different
>  > maintainers...)
>  >
>  The DESTDIR change is mandatory in Gentoo to install properly a package.
>  I don't know how it can be centralized in root makefile since this root
>  makefile calls each project makefile to do the installation. The most
>  problem is that the root makefile does compilation and installation for
>  some subdir but rely on sub-makefile for the others! I think the root
>  makefile must be as simple as possible and call the sub-makefile for all
>  real works. This way allow also to modularize properly each sub-project
>  so they can be installed outside Kepler.

Sure, I understand the motivation. But many of the sub-makefiles are
very old and for some of them I had to jump some hoops to keep the
"modernization" work concentrated in the root Kepler makefile (some of
them are ignored entirely by the root makefile). As mentioned before
in the Kepler list, the big root makefile was an attempt to make
Kepler easier to build and to study the requirements on Lua module
building, work which eventually used in LuaRocks.

>  Concerning the build system used, what about a change to a more powerful
>  system, like CMake or SCons? I've heard of LuaDist that use CMake to
>  build/install a complete Lua system.

We're happy with makefiles and LuaRocks.

> > Again, thanks for the patch, but I don't know how much effort should
>  > go into improving this installer. The future of the monolithic Kepler
>  > package for Unix is uncertain nowadays, as the focus is going into
>  > making a LuaRocks-based Kepler install.
>  >
>  LuaRocks may be a good way to do, but existing solution to install
>  Kepler from sources with good dependencies handling (like Gentoo ebuild
>  system) should be maintained. Someone, like me for example, may prefer
>  to deal with only one build/install system. Gentoo ebuilds that use a
>  "LuaRocks" eclass to install (from sources) should be a nice feature.

Yes, that would be nice. There have been conversations in the LuaRocks
list about writing ebuilds that use LuaRocks.

-- Hisham