Loading ...
Sorry, an error occurred while loading the content.

51951Re: (patch) Lua interface

Expand Messages
  • Tony Mechelynck
    Sep 4, 2008
      On 04/09/08 16:37, Paul Moore wrote:
      > On Sep 4, 2:44 am, Luis Carvalho<lexcarva...@...> 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.

      1. If the interface uses a separate DLL, then the absence of that DLL
      must not prevent Vim from running (as long as the interface isn't used,
      of course).

      2. If the DLL must be linked with the same C runtime as every program
      with which it is used, there's little advantage in having a separate
      DLL. It might even be outright dangerous to use it.

      Therefore I believe that the way to go is to link the Lua interface (if
      enabled) statically into Vim. Or else, maybe, as a DLL of a different
      name, compiled and distributed together with Vim, and installed in
      $VIMRUNTIME; but there might be licensing problems with the latter approach.


      Best regards,
      Tony.
      --
      Miss, n.:
      A title with which we brand unmarried women to indicate that
      they are in the market.
      -- Ambrose Bierce, "The Devil's Dictionary"

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Show all 28 messages in this topic