On Sep 4, 2:44 am, Luis Carvalho <[EMAIL PROTECTED]> wrote: > > Anyway, as for your question I'd say just default to using a shared lib. > > Most other interfaces seem to do so, and I'd say the costs should be > > neglectable in this case. On Windows looking up the required symbols at > > runtime seems to be the most popular choice, though I personally don't > > care to much about it either way. > > That makes sense. I've updated configure.in to link a shared lib.
On Windows, things get a little odd, as linking Lua as a DLL has 2 negative effects: 1. If lua51.dll isn't present, Vim won't start. This is fixable, but needs code changes to load the DLL at runtime. The other language bindings do this - I think I can do something similar for Lua with less code changes, based on a recipe from the Lua wiki. Let me know if you'd like me to try. 2. Vim needs to be linked with the same C runtime as the Lua DLL. In practice, this means that most existing Lua binary DLLs won't work, as they use the msvcrt8 runtime, which isn't normal for Vim. You can build your own Lua binary DLLs, but if you're doing that, you can probably also recompile Vim reasonably easily. I'd suggest defaulting to linking Lua statically on Windows, with a DLL link as an optional alternative. That's what I did in my second Make_ming.mak patch. Let me know if you want me to do the dynamic DLL loading change. I'll tidy up and update my Make_ming.mak patch in any case. Regards, Paul. PS In case it's not obvious, you have my full permission to include the changes I'm posting into your patch, should you wish. --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
