Re: [ANNOUNCE] Lua 4.1 (work4)

[nop@...]

On 18 Feb 2002, John D. Ramsdell wrote:

> erik@hougaard.com (Erik Hougaard) writes:
> 
> > But the main problem is still, that Lua is two different things to different
> > people. We have the script guys who just want to download/install/use, and
> > then we have the embedded people (including my self) who embeds Lua into all
> > sort of different thing and we dont care about makefiles cause we need it to
> > be part of our own build system, so we are most more interested in keeping
> > Lua 100% ANSI-C without tons of preprocessor defines that would collide with
> > the application that we embed Lua into.
> 
> For embedded people, shouldn't it be possible that a Lua header file
> and a shared library are placed in some appropriate public places.
> Embedded usages of Lua compile source files using the interface
> declared by the public header file, and then link in the shared
> library at runtime.  In this model, the script engine is just another
> consumer of the shared library.  It is compiled by including the
> public header file, and it links to the shared library at run time.
> It's no different than any other embedded user of the library.

I think I see a miscommunication here.  The word "embedded" is being
used in two different ways.

Embedding Lua into applications, in the way that Tcl advocated.
Typically, you're on a conventional workstation.  Shared libraries are
appropriate if you have a deployment environment that can cope with
them.  Some people want to ship as a single executable, for a number
of reasons (some good, some bad).  For example, for a long time
Windows installers and practices in using them discouraged the
deployment of DLLs except when unavoidable.  And when shipping
cross-distro Linux binaries, there are often pressures to link as much
as possible statically, to avoid package dependencies.

Using Lua in embedded systems.  Most embedded systems have
environments that have little in common with the typical workstation.
For instance, I can almost see using Lua in a boot monitor.  To build
such a thing, there's a lot of custom work in the production of linker
scripts and ROM imaging output to get an executable. And since there
may not even be *files*, shared libraries are unlikely.

> In any event, the use of autoconf could be easily used to create this
> setup.  Building and installing shared libaries is well supported.
> There should be no conflict between embedded and scripting Lua users.
> Embedded poeple should be able to use Lua as a shared library if that
> best suits their needs.  Or they may simply want to copy the sources
> into there source tree.  Whatever works...

Shared libraries on Unix are a huge pain to get right if you're trying
to support more than just Linux, *BSD, and Solaris.  These days, many
new projects delegate the details of shared library production to GNU
libtool....

Jay