RE: Lua in .deb form

[Philippe Lhoste <PhiLho@...>]

John Belmonte wrote:
> Daniel Silverstone wrote:
> 
> > When writing their own lua interpreters, people tend to end
> > up linking statically, you can now link against lua dynamically
> > and gain all the size benefits when you have lots of different
> > lua interpreters lying around.
> 
> So the binary package includes the headers and library?  I 
> thought something
> like that belongs in a -dev package?
> 
> Anyway, especially with 4.1, there are several configuration options
> implemented with compile-time macros.  This limits the usefulness of
> pre-built libraries (both static and dynamic), and will lead to confusion
> when an app tries to use options that were different than used to compile
> the library.  As Lua becomes more configurable in the future, 
> this will only
> get worse.  Lua places priority on time and space efficiency so 
> I'd imagine
> that low-level options will always be configured at compile-time.
> 
> Why dynamic link when Lua is so tiny?  I'd even go beyond recommending
> static linking to a pre-built library, and say just include the library
> source code in your project.  Besides eliminating the compile-time
> configuration issue, it has the advantage of isolating your app 
> from future
> Lua changes.  Ten years from now your app could still be using Lua 4.1
> because it does everything you need, regardless of the versions active in
> Debian.

Your arguments are valid, of course, but can be argued.
On one side, you have a stable application, using a well known and
compatible version. If Lua goes to an incompatible change, like it did from 3 to 4,
the application will still work.
On the other side, if Lua goes to a minor upgrade, eg. 4.0 to 4.1, you won't
be able to upgrade unless the programmer recompiles the whole application,
so you will loose improvements like the new Date functions, the improved
scoping, or the gain of speed.

As always, that's a matter of choice. For an application using closed
scripts (like a game), it is better to rely on a frozen version. For applications
using user provided scripts, users can benefit from being able to upgrade
themselves to the next version of Lua, as long as the API is compatible. But this
can break some existing scripts (probably mostly on the libraries side).

Of course, this can lead to DLL hell, so the solution better have to been
well though (like being able to select which DLL/shared library to load).

Regards.

-- 
--._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/
--´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`--

Sent through GMX FreeMail - http://www.gmx.net