Hi Bram, 2016/1/2 Sat 22:14:01 UTC+9 Bram Moolenaar wrote: > Ken Takata wrote: > > > 2016/1/2 Sat 6:30:39 UTC+9 Bram Moolenaar wrote: > > > Ken Takata wrote: > > > > > > [...] > > > > > > > 3. Updated if_xx > > > > ActivePerl 5.22 > > > > ActiveTcl 8.6 > > > > LuaBinaries 5.3 > > > > Python 2.7 > > > > Python 3.4 > > > > RubyInstaller 2.2 > > > > > > I'm updating my Windows machine with these. I'll use Python 2.7.10 > > > (since 2.7.11 has a problem). > > > > > > Unfortunately, Vim can't load "python35.dll". I tried re-installing, > > > but that didn't help You mention Python 3.4, does 3.5 not work? > > > I'll stick to 3.4 for now, it appears to work. > > > > Before 3.4, pythonXX.dll was installed into the system directory > > (C:\Windows\System32 or C:\Windows\SysWOW64), but after 3.5, python35.dll > > is not installed into the system directory. So if you want to use 3.5, > > you must add the python35.dll's directory to the PATH environment. > > Using 3.4 is easier than 3.5. > > I had copied the python35.dll to c:\windows\System32 but that didn't > help. Unfortunately the only error is that the file can't be loaded, > there is no hint why. I suppose that even when the file is found there > can still be other reasons why it can't be loaded. Anyway, Python 3.4 > is good enough.
I suppose you use 32-bit Vim on 64-bit Windows. If so, you should copy python35.dll to C:\Windows\SysWOW64 (not System32). System32 is a system directory for 64-bit programs, and SysWOW64 is for 32-bit programs. > > > I tried Ruby 2.2, but it appears it doesn't work with MSVC. > > > The config.h include file is in include/ruby-2.2.0/i386-mingw32. > > > Trying to change the path for that results in a missing "strings.h" > > > include file, I assume that's from MingW. > > > > As I wrote in this post, I do some hacks on AppVeyor: > > https://groups.google.com/d/msg/vim_dev/dAXpcpHmVw4/zz_NoTUICwAJ > > > > 1. Download Ruby 2.2's source code and generate config.h: > > > > cd C:\projects > > git clone https://github.com/ruby/ruby.git -b ruby_2_2 > > cd ruby > > call win32\configure.bat > > nmake .config.h.time > > > > There is no need to build whole Ruby, just config.h is needed. > > The config.h is generated in the .ext\include\i386-mswin32_100 directory. > > > > > > 2. Adjust some variables when building Vim > > > > nmake -f Make_mvc.mak ^ > > ... ^ > > RUBY=C:\projects\ruby DYNAMIC_RUBY=yes RUBY_VER=22 RUBY_VER_LONG=2.2.0 ^ > > RUBY_INSTALL_NAME=msvcrt-ruby$(RUBY_API_VER) ^ > > RUBY_PLATFORM=i386-mswin32_100 ^ > > RUBY_INC="/I $(RUBY)\include /I $(RUBY)\.ext\include\$(RUBY_PLATFORM)" ^ > > WINVER=0x500 > > > > Normally we need to set only RUBY, DYNAMIC_RUBY, RUBY_VER, RUBY_VER_LONG and > > WINVER. (WINVER must be set to >=0x500, when building with Ruby 2.1+.) > > But when using this trick, we also need to set RUBY_INSTALL_NAME, > > RUBY_PLATFORM and RUBY_INC. > > Instead of that, can we copy the generated config.h into the installed > Ruby directory, next to the MingW one? Or does that not work? If we copy ".ext\include\i386-mswin32_100\config.h" (when using 32-bit VC10) to "C:\Ruby22\include\ruby-2.2.0\i386-mswin32_100\config.h", we don't need to set RUBY_INC, but we still need to set RUBY_PLATFORM and RUBY_INSTALL_NAME. Because: 1. The current Make_mvc.mak doesn't set RUBY_PLATFORM properly when using VC7 or later. 2. RUBY_INSTALL_NAME is used for the DLL name, and the name is different when using different compiler. E.g. MSVC10 32 bits: msvcr100-ruby220.dll MinGW 32bits: msvcrt-ruby220.dll MSVC10 64 bits: x64-msvcr100-ruby220.dll MinGW 64bits: x64-msvcrt-ruby220.dll We want to link Vim built by MSVC with RubyInstaller built by MinGW, so RUBY_INSTALL_NAME must be set manually. Now I'm trying to update Make_mvc.mak to set RUBY_PLATFORM properly, but even if I succeeded this, we still need to set RUBY_INSTALL_NAME. > > RUBY_PLATFORM becomes different value when you use different compiler. > > E.g. If you use 64-bit VC2013 (=VC12), RUBY_PLATFORM is x64-mswin64_120. > > > > When you build 64-bit version, RUBY_INSTALL_NAME must be set to > > x64-msvcrt-ruby$(RUBY_API_VER). (Oops, I made a mistake in the > > appveyor.bat.) > > > > With these tricks, Vim can use the dll from RubyInstaller. > > Can we please gather the complete, step-by-step instructions? Probably > the best place for this is src/INSTALLpc.txt. I need time for this. > > > I had not built with Lua, can't find instructions on how to do it. > > > > I use LuaBinaries (http://luabinaries.sourceforge.net/). > > I downloaded lua-5.3.2_Win32_dllw4_lib.zip from the download page. > > Well, then you have a .zip file. Then what? OK, how about this: X. Building with Lua support ============================ Vim with Lua support can be built with either MSVC or MinGW (or maybe Cygwin). You can use binaries from LuaBinaries. (http://luabinaries.sourceforge.net/) 1) Download and install LuaBinaries Go to the Download page of LuaBinaries: http://luabinaries.sourceforge.net/download.html Download lua-X.Y.Z_Win32_dllw4_lib.zip for x86 or lua-X.Y.Z_Win64_dllw4_lib.zip for x64. You can use them both for MSVC and MinGW. Unpack it to a working directory. E.g. C:\projects\lua53. Lua's header files will be installed under the include directory. {{{ (This part is for users. Maybe it's better to move to if_lua.txt?) Copy luaXY.dll to your Windows system directory. The system directory depends on your Windows bitness and Vim bitness: 32-bit Vim on 32-bit Windows: C:\Windows\System32 32-bit Vim on 64-bit Windows: C:\Windows\SysWOW64 64-bit Vim on 64-bit Windows: C:\Windows\System32 Or another option is copying luaXY.dll to the directory where gvim.exe (or vim.exe) is. }}} 2) Build You need to set LUA, DYNAMIC_LUA and LUA_VER. LUA: Where Lua's header files are installed. E.g. C:\projects\lua53. DYNAMIC_LUA: Whether dynamic linking is used. Set to yes. LUA_VER: Lua version. E.g. 53 for Lua 5.3.X. E.g. When using MSVC (as one line): nmake -f Make_mvc.mak LUA=C:\projects\lua53 DYNAMIC_LUA=yes LUA_VER=53 Or when using MinGW (as one line): mingw32-make -f Make_mingw.mak LUA=C:\projects\lua53 DYNAMIC_LUA=yes LUA_VER=53 > I spent too much time yesterday trying to do things that should be > simple, but turn out to be a big forest of options, choices and > failures. Some installers ask tons of questions that I don't know the > answer to. And now my $PATH is filled with directories that no longer > exist... > > We should really have one place, with a nice step-by-step list of > instructions for every interface. Mainly for those who build Vim. > But there should also be a section for users, how to install the stuff > needed to run the interface. This should be in the help. > > Since you have most of this figured out, can you please write this down? > And then have someone with a "clean" system follow them and check for > any missing pieces. I also need time for this. Regards, Ken Takata -- -- You received this message from the "vim_dev" 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_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
