[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANNOUNCE] Lua 4.1 (work4)
- From: ramsdell@<a href="/cgi-bin/echo.cgi?linus.mitre.org">...</a> (John D. Ramsdell)
- Date: 18 Feb 2002 09:03:30 -0500
firstname.lastname@example.org (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.
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...