Re: [ANN] Vim for Windows build, contains all 3rd party dependencies

On 01/01/2015 23:11, Justin M. Keyes wrote:
> On Thu, Jan 1, 2015 at 12:37 PM, Shiny Bling <kybuliak@gmail.com> wrote:
>> On Wednesday, 31 December 2014 19:51:20 UTC+1, Steve Hall wrote:
>>> On Wed, Dec 31, 2014 at 12:41 PM, Shiny Bling <kybu...@gmail.com> wrote:
>>>> My main reason doing the build is that Vim Windows builds like the
>>>> above don't include 3rd party dependencies(ruby, python, ...). You
>>>> have to install them yourself. I needed ruby for some plugin and when
>>>> I added it, the whole Vim process was crashing. There was also a case,
>>>> when I downloaded some Vim build and it required Ruby version, which
>>>> was not yet released at http://rubyinstaller.org/
>>>
>>> You can use the dynamic flags for several dependencies to avoid this.
>>> My builds use them for these major ones:
>>>
>>>
>>> +gettext/dyn
>>> +iconv/dyn
>>> +lua/dyn
>>> +multi_byte_ime/dyn
>>> +perl/dyn
>>> +python/dyn
>>> +python3/dyn
>>> +ruby/dyn
>> In order for that to work reliably, the end user has to install exact dlls which were used during the build. Otherwise, Vim can crash if there are compiler ABI incompatibilities(mingw vs Microsoft compiler) or incompatible function signature changes in the dlls. Let alone the fact, that the end user has to install dlls of languages he might have no idea about only because they are required by plugins. I think that for a smooth experience, it should be all distributed together. That is how it works in Linux distributions.
> Well, except that python/ruby/etc are managed by the package manager.
True, managed by the package manager and the whole system is compiled
with same compiler version and system libraries. Unlike on Windows,
where you need at least redistributable runtimes for each Visual Studio
version installed programs were compile with. I don't think OneGet will
change that. More likely, there will be packages like vim-mingw and
vim-msvc depending on a compiler the package was compiled with.

> Windows 10 will ship with a package manager:
>
> https://github.com/OneGet/oneget
>
> So hopefully the situation will improve.
>
>
> However, vim-single-drop is a great effort. I tried it and didn't find
> any problems with it, except that it doesn't ship with luajit.
> http://files.kaoriya.net/vim/ ships with luajit, and the performance
> difference for lua-heavy plugins like unite.vim is significant.
Thanks for a heads-up, I didn't know about unite.vim nor luajit. I will
add them in.

> What is your strategy for scenarios where users what to install
> python/ruby packages with pip/gem?
I was already thinking about it and a solution could be to include the
3rd party
dependencies completely, with all executables, etc ...

> What happens when they update vim-single-drop?
Good question, I haven't thought of this one yet.

> What happens if they have ruby or python already
> installed and on their $PATH, and expect some package to be available,
> but it isn't because vim-single-drop uses a different site-packages,
> etc.?
Well, at that moment they realise this vim build does not use those ;)
Maybe in reality it won't be an issue as most plugins don't have heavy
dependencies.
And if it is so, users can use gem/pip included into the vim build, as
mentioned above, to install missing dependencies.

kybu

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.