[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Feature proposal: separate export macro for standard library modules
- From: Thomas Lauer <thomas.lauer@...>
- Date: Tue, 24 Nov 2009 09:22:41 +0000
Jerome Vuarand <firstname.lastname@example.org> wrote:
> 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.
+1 as I've run into the same set of problems.