Re: More about packaging

["D Burgess" <db@...>]

If the current scheme is to be modified:

1) Unloadlib support please. (For Win32 - FreeLibrary())

2) Do not base the solution on naming conventions, it
can be difficult to make conevntions consistent across
all platforms. (e.g. external library names)

>> For loading (OS dependent) libraries, i believe a function like
>> 'require(...)' would help.
>
>The fancier loadlib that I sent in the original post kind of solves the
>problem of platform dependent library names and locations, more or less
>in the same way your requireso does. What I would like to solve is the
>problem of a library not knowing whether it's being loaded statically or
>dinamically.
>
>The user script will call "require" anyways, but suppose whoever built
>the interpreter decided the library should be linked statically. Calling
>require would probably fail, not finding the file. For Lua libraries,
>maybe if we modify the _LOADED table appropriately, we can prevent
>require from failing. The Wiki suggests having a simple Lua loader for
>each dynamic C library. This allows users to use require both for Lua
>modules and dynamic libraries. I like the idea, but it would be nice to
>have the static vs dynamic transparency built in, and this is what I
>wanted to discuss.
>
>For libraries that have both a C part and a Lua part, the thing gets a
>little messier. Our smtp module needs help from C, so we have smtp.lua and
>smtp.so. I wonder what is a clean way of loading such a
>module, that works both statically and dynamically when the user
>script calls require"smtp"...
>
>[]s,
>Diego.