[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua within Debian
- From: Jay Carlson <nop@<a href="/cgi-bin/echo.cgi?nop.com">...</a>>
- Date: Mon, 11 Feb 2002 21:51:49 -0500
On Monday, February 11, 2002, at 06:57 PM, Daniel Silverstone wrote:
On Mon, Feb 11, 2002 at 09:45:46PM -0200, Luiz Henrique de Figueiredo
I noticed you didn't expose lua_loadbuffer as an external symbol in
the shared library.
Lua 4.0 officially has no lua_loadbuffer and friends.
*Please*, package the official Lua 4.0 code. You may want to add the
as a separate thing, of course. Thanks.
Hmm, I can either package it in the "Debian version" of lua 4.0 or
could provide an "alternative" liblua package.
My current favourite is to make the symbol exposed but guard the
of it in lua.h with something like
How does that sit with people?
The only other thought I have is to NOT change their names, but just
remove the static flag. That way, liblua.so is not exporting anything
new in the public lua_foo namespace.
The alias lua_loadbuffer could then be applied either through a #define
or a function exported in another library. Or maybe better yet, we
throw it in the Debian namespace like dllua_loadbuffer.
In any case, the goal is to make sure developers using this function
understand that it is not a standard function. If Debian users were
building from source, we could just tell them to apply a patch to the
pristine sources, but they use binaries, and there are significant
benefits to maintainers, developers, and end-users in not shipping two
conflicting versions of a shared library when the differences are so
(BTW, Debian regularly ships heavily patched versions of other
interpreters. tk8.0 through tk8.2 ship not only with a full set of
internals include files, but also with the "plus" patch applied, which
exports significant user-visible functionality.)