Building a 64-bit Vim with Python support on Windows 7

I spent a good day trying to build 64-bit vim with Python support, and if I had just known these two tips, I could have saved an enormous amount of time:

  1. Install Microsoft .NET Framework 4.0
  2. Make sure Python is in your PATH

Part 1: Building Vim

I’ve built vim before, quite a few times. It’s not that different from building git. It does require some configuration, but it generally just works, without errors or warnings, whatever platform you build on.

Unfortunately, I fell victim to the Google school of debugging instead of debugging my problems on my own. It turns out that there is a “bug” in the Windows SDK 7.1 in that it does not install all of its dependencies. This has nothing to do with Vim specifically, it turns out this prevents you from building anything with a dependency on a resource file (.res).

Here’s a recipe for building vim on Windows 7 with the Microsoft SDK:

  1. Install Microsoft Windows SDK 7.1
  2. Install .NET Framework 4.0 (4.0. Not 4.5, not anything else, 4.0!)
  3. Open the Windows SDK 7.1 Command Prompt and run: setenv /release
  4. Make sure you are in the 64-bit environment, and ensure that you can run the command: cvtres
  5. If you get this dialog, you didn’t follow step 2.cvtres_dep_error
  6. Install the official 64-bit Python (2.7 series)
  7. Clone vim: hg clone https://vim.googlecode.com/hg/ vim
  8. Set up your environment for the build:
    set PYTHON=C:\Python27
    set PYTHON_VER=27
    set DYNAMIC_PYTHON=yes
    set FEATURES=HUGE
    set OLE=yes
    set GUI=yes
  9. 7. Build it, as per the instructions:
  10. cd src
    nmake -f Make_mvc.mak

You should have succesfully build a gvim.exe. The trouble I ran into was this obscure error during the link phase:

fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt

After Googling, I found that there was a compatibility problem, and it had something to do with .NET. But, I really had no idea what anyone was talking about other than the suggestion to use another version of CVTRES.exe that I did not have. If I had just attempted to actually debug the problem, I could have set the /VERBOSE flag and run the LINK command again to see what the problem was. This identified CVTRES.exe as the culprit, and so I tried running CVTRES.exe. That’s when the error dialog finally popped up and it became obvious. The LINK program was ignoring the error from the program and somehow preventing it from popping up, and then telling me its output was invalid…

Building an NSIS installer did not work out-of-the-box. I had to make a number of modifications to the NSIS script to get it to work. I would have preferred to use the Cream installer script, but it doesn’t seem to be openly available. I’ve posted my modification on a fork on Bitbucket.

In the next episode, I’ll explain the details of how I was led astray by Python not working in my build (perhaps the blame does not fall entirely on me, though).

This entry was posted in Uncategorized. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

4 Comments

  1. Haroogan
    Posted January 25, 2013 at 8:25 pm | Permalink
    • Posted January 26, 2013 at 11:38 am | Permalink

      I’ll give it a try. I didn’t include Python 3 simply because I don’t generally use it. I did want to include Ruby but I ran into some issues with that, since the RubyInstaller is built with mingw.

      The one thing you’re missing is the installer. I’m hoping I can contribute the installer fixes back to vim soon so it will build out of the box. I’m also going to see whether the Cream installer source is available since I prefer it to the stock Vim one.

  2. Haroogan
    Posted January 26, 2013 at 12:38 pm | Permalink

    Personally, I like software to be portable – never used the official Vim installer – just can’t see the point of it. If by the installer you mean the integration of “Open with Vim” option into the Windows shell – then yes – I use it too and it’s definitely a good feature. However, I simply wrote a Python script which does this integration for me. I decided not to bundle this script with the distribution because I thought some people may consider it intrusive.

    By the way, I’m looking forward to include Ruby support in future – some people use Command-T plugin extensively, and it requires Ruby.

    Best regards.

    • Posted January 27, 2013 at 2:47 pm | Permalink

      We’re probably on different sides of the philosophical fence here. I am strongly in favor of installers for Windows to maintain software. There’s no automatic ‘undo’ for unzipping a zip file somewhere. The current vim installer actually adds too much stuff by default, so I’m not a big fan of it, but I do want a start menu item and the option to open with Vim.

      I’m not as urgently trying to build with Ruby because I discovered ctrlp.vim which is actually a pure Vim alternative to Command-T and works even better. I had been using tuxproject.de builds of vim for a while to support Command-T.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>