Re: 5.1 package proposal and Kepler libs

--Apple-Mail-3--402694208
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1; format=flowed


El 06/12/2004, a las 13:01, Martin Spernau escribi=F3:

> Adrian: if you have time it would be very usefull if you could=20
> evaluate the Compat-5.1 integration into LuaCheia. See what would be=20=

> needed and where possible problem are, and maybe report those findings=20=

> here on the list.

After diving a bit into compat-5.1 this afternoon, the following=20
changes are needed if we want to have the new module system:

The "compat-5.1.lua" script must be loaded before all other=20
scripts/modules, so the appropiate module() and require() functions are=20=

defined by it. I propose to load it from "luacheia.lua" (our=20
bootscript). A good place to load it is at the end, so we don't break=20
things from our bootscript.

As "compat-5.1.lua" can use LUA_PATH to find scripts and LUA_CPATH for=20=

binary modules, we must add the LuaCheia paths to that variables. I=20
think the best approach is from "luacheia_wrapper.c": if the variables=20=

exist, LuaCheia's paths are appended to them; otherwise the variables=20
are created before spawning the Lua interpreter.

Finally, the C functions defined in "compat-5.1.c" should be in the=20
"liblualib.{a,so}" shared libraries, so it's available to C modules=20
using the new API. I though two possible solutions:

    A.)  Link "compat-5.1.o" into "lauxlib.{so,a}", and merge the=20
function definition from "compat-5.1.h" into "lauxlib.h". This approach=20=

modifies Lua sources, but migration to 5.1 will be easier, as things=20
will be in the right place without touching anything.

    B.)  Build a "libluacompat-5.1.a" library (static only) with the=20
extra function and install the "compat-5.1.h" header; the modules=20
include that header when HAVE_COMPAT_5_1 is #defined; tweak=20
"configure.ac" so that preprocessor macro gets defined and link the=20
modules against "libluacompat-5.1.a". This approach does not modify=20
official Lua sources, but when 5.1 gets released, we will have re-edit=20=

Makefiles and "configure.ac"


As a final remark: modifying "lauxlib.h" to include "compat-5.1.h"=20
could be done from a shell script using sed/awk, or even using the Lua=20=

interpreter after it gets built :-P, and *before* modules are built.=20
The Lua sources won't get modified "per se": the nonstandard=20
"lauxlib.h" will be installed in the system and used to build modules.=20=

It's a bit tricky, but we in this case we'll have the easy migration to=20=

Lua 5.1 without touching Lua 5.x sources.


Regarding module adaptation to the new module system, if we don't zap=20
the "cheia.load", "cheia.loadlib" and "cheia.gluaload" functions we can=20=

still load our modules without modifying them. New modules or adapted=20
ones can be loaded with the new "require()" implementation shipped into=20=

"compat-5.1.lua". When loading a module that uses the new module system=20=

via the "cheia.load" function we can print some kind of "deprecation=20
warning" to stderr. Somewhat in the future we'll have to bury=20
"cheia.load" and friends deep in the earth as a phantom of the past=20
xDDDD


I will be looking forward your comments/suggestions/flames/whatever on=20=

the topic.

Have a nice day!

-ap

--Apple-Mail-3--402694208
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: Mensaje firmado digitalmente
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAkG2LsIACgkQghBwwjayrGQT8ACfa9KTM6jiXfqXP24k021E1At8
CqUAoIxJ5EeuLN1b3Kk+6BX4KRmGkvZb
=orhw
-----END PGP SIGNATURE-----

--Apple-Mail-3--402694208--



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/