lua-users home
lua-l archive

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

On Tue, Jun 15, 2010 at 9:43 PM, Luiz Henrique de Figueiredo
<> wrote:
>> Since that discussion, Yaakov Selkowitz has uploaded a Cygwin package
>> [1-3].  This provides shared library support (cyglua-5.1.dll), which
>> "make linux" under Cygwin does not.  Note the patches applied in the
>> Lua cygport source distribution [3].
> Nice downstream packaging. So, no need for a cygwin target, right?

On Tue, Jun 15, 2010 at 8:28 AM, Luiz Henrique de Figueiredo
<> wrote:
> The situation of src/Makefile is slightly different: it is an executable
> documentation of which files depend on which (which gcc can generate)
> and of which flags work in which platforms (which is a pain to discover
> if you don't know). But src/Makefile is not really needed if you only
> want to build the Lua interpreter: use etc/all.c (or etc/one.c in 5.2).
> Again, my motivation is to have the simplest possible files that are
> helpful but not a source of noise. So perhaps we can simplify the Makefiles
> and still be useful without being in the way of users and packagers.

I use the build files from the Lua distribution (src/Makefile and
luavs.bat) primarily for quickly building Lua to test some idea or
benchmark.  So, my typical targets are linux/posix (for
readline/io.popen support), ansi, and clean, as well as sometimes
luavs.bat.  These build files are not really suitable for reuse in my
production builds or installations though.

So in my use case, yes, the current Makefiles are both more and less
than what I'd like.  A small script like luavs.bat can be sufficient,
easily understood, and adapted, though slower to rebuild.   OTOH, I'd
prefer the standard Makefiles to support quickly building a shared
library for testing Lua modules like lpeg and luasocket.  Think of the
case of a new Lua developer who wants to experiment with building
things like this.  A typical user needs to figure out the recursive
Makefiles and hunt around for compile flags.  LuaRocks/LuaDist help
here, though they alter the usual build steps.

So, I'd vote for including a Cygwin target in src/Makefile for
building shared libraries on Cygwin, which is only a few lines [1],
but not necessarily going beyond that.

BTW, one of the aims in autotools, cmake, and premake is not to have
you define the build process for each platform but rather describe the
things you want built on a more conceptual level, which tools can then
interpret to generate platform-specific build files for you.  My
example of mechanically translating a rockspec to a Makefile [2] is
similar to this.