lua-users home
lua-l archive

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

2009/9/7 George Petsagourakis <>:
> I really appreciate the efforts of all authors that
> contribute C modules for Lua. It really makes it clear
> that Lua community is very much alive and kicking.
> As much as I love Lua, I am a Windows guy and that
> as a fact is making hard for me to appreciate the
> functionality of such modules. I am pretty sure that
> there are even more people that hit a full stop when
> they encounter the need to compile a specific Lua
> extension that they have found.

To those who live in a Windows world, the non-distribution of binaries
can be mystifying or infuriating. Equally, to those of us who live in
a standards-based world, life is simply too short. The project to
which I devote most time, GNU Zile, runs on over 20 platforms. I don't
distribute binaries for any of them, even the one I use, as it's not
easy. There are at least two things to consider: first, distributing
compiled Cprograms. I could cross-compile for Windows, but it turns
out that even Windows users can't agree on what C runtime to use, so
I'd have to ship 2 or 3 flavours. Secondly, there's platform-specific
packaging. I don't have time to learn how to package for Windows,
Cygwin, Ubuntu, Debian, RedHat, FreeBSD, NetBSD, OpenBSD &c., and
there's no tool I'm aware of that lets me automatically package for
all of them. (This is not a surprise, as Linux distributions at least
tend to have quite complex packaging rules.) In any case, for most of
the programs I work on, there are already people packaging them for
most platforms.

Perhaps a more cogent question to ask is why people still use C, when
they could at least solve the executable side by languages which are
either interpreted or compiled to a platform-neutral format, such as
the JVM or CLR. But again, the answer is obvious: we still use a lot
of software written in C, so we want to bind to it.

One might also plead specially in favour of the few platforms with the
most users, Windows chief amongst them, and indeed many programs, Lua
included, have binary distributions for Windows, GNU/Linux and Mac OS.
But as contributors to this thread have already said, we don't all
have the time or motivation for that.

Personally, most of my C programs are distributed in source form with
a GNU autotools build system. This is the best I can do for the
largest number of users: my end of the deal is simply to write to
various standards, mostly POSIX, and autotools takes care of the
platform (including Cygwin and MingW on Windows, but sadly, as far as
I know, not the Microsoft toolchain). If something as easy to use as
autotools with the same range of support came along tomorrow, I might
well consider using it; in the mean time, I write as little C as I can
(most of the code I write these days is in Lua or Perl).

> The lack of C knowledge is a severe hit to the common
> Lua scripter,

Not really. With distribution systems like gems or even good old
autotools, you don't need to know anything about programming, you just
need a toolchain installed and be able to read a README and issue a
command or two. Unfortunately, Windows does not make this an
attractive option; I'm glad to see that these days at least Mac OS

> although the module authoring in its
> entirety (only some few commentable efforts are excluded)
> is ignoring the windows operating system and doesn't
> release compiled binaries for the win32.

That's not "ignoring the Windows operating system", that's "not making
special allowance for the Windows operating system". Most of my C
programs run on Windows (though its standards support, unless you go
to third parties, is not what it should be).

The points that other contributors have made about the ability to read
and fix source code are of more minority interest: trojans are just as
easy to insert into source as into binary code, while being able to
fix or improve code, a freedom I exercise and value highly, is not of
interest to many users per se (though its existence is important).

Music is sweetest when it almost stops