Feature proposal: separate export macro for standard library modules

[Jerome Vuarand <jerome.vuarand@...>]

Hi list,

Recently, while building a monolithic application using Lua statically
built-in, I've faced some problems due to the fact that the standard
library loaders (luaopen_*) use the same export model than the Lua C
API. The loaders use the LUALIB_API macro to export themselves from
DLLs on Windows. In my app however, I wanted to keep the Lua API
private, but still export the modules loaders, so that I could write a
custom searcher that reflectively calls GetProcAddress on the exe
itself to get modules loaders.

So I've written the patched attached to this email to use a separate
macro, LUAMOD_API, for all standard library module loaders. If not
defined, that macro is defined to LUA_API in luaconf.h. It would be
nice to have it integrated in the next Lua version, since that doesn't
impact normal Lua builds, but adds a bit of flexibility for
specialized applications.

For the sake of completeness, another potential use of that patch,
completely opposite to the one described above, would be the ability
to build a Lua DLL that exposes the Lua C API, but not the modules
loaders. Since luaL_openlibs already references them, is is not
strictly necessary to export them. Of course by default with the patch
above they would be exported (since it's a normal Lua use case to use
a custom linit.c).

Finally that new macro could become a standard for module writers to
export their modules. For example LuaFileSystem uses a .def file,
while LuaSocket uses LUASOCKET_API. Something more consistent would
greatly simplify application developpers that want to use binary
modules in an exotic way, like in the type of monolithic build I've
mentionned above.

Feel free to comment, and I'd be glad to adapt the concept to
something closer to the authors plans for the future of Lua.

Doub.