Vim — the editor

Vim: Compiling HowTo

for Vim on 32-bit Windows systems
 
Last change: 2011-12-24 09:53 UTC 		Back to "The Vim Editor"
Back to Welcome page
 
This HowTo is based on Steve Hall's, with a few changes to reflect my own way of work. One significant difference is that I don't edit the Makefile. It covers two different free compilers: Borland BCC32 and cygwin gcc. Even when building with gcc, the method described does not require the Cygwin DLL to be available to run Vim. For other compilers (not tested by me), download the sources as in «Once per release» below, and see the file INSTALLpc.txt in the "src" directory.
  1. Once and for all
  2. Once per release
  3. Every time
  1. Once and for all: Make sure you have the required software tools and settings, as follows. They can use up a lot of disk, up to 300M or so for a full Cygwin installation, so be prepared.
    • Cygwin: Install everything if you can afford the space. Otherwise, install the basic utilities, including bash etc., plus at least man, bzip2 and patch. (WinZip doesn't always know about the bz2 format; and AFAIK, the cygwin patch program is the only patcher for W32 that doesn't choke on the Vim patches.) Include also gcc and make if you want to compile using cygwin. Also gdb if you want a debugger.
    • The free Borland compiler: If you want to compile using Borland BCC, install at least the "C Builder Compiler and Incremental Linker". Install the "Turbo Debugger" in addition if you want to do source-level or machine-instruction-level debugging.
    • Perl, Python, and/or Ruby and TCL: If you want Vim to be able to interface with them, you must have them before compiling Vim.
    • If you want TCL, then if you use the Borland compiler you should also install Dan Sharp's TCL stub, which accommodates config differences between BCC and MSVC. Drop it in your src directory, and make sure that it is called tclstub83-bor.lib and not tclstub83-bor.lib.html (If your browser renames it, rename it back).
    • For Ruby, you may need (as is noted in the makefile) to comment away the defines for uid_t and gid_t in %RUBY%\lib\ruby\%RUBY_VER_LONG%\i386-mswin32\config.h because they conflict with typedefs in %BOR%\include\sys\types.h. In addition, whatever your compiler, search the same config.h file for the lines 
      #if _MSC_VER != 1200
#error MSC version unmatch
#endif
      which generate a compile error in every C compiler other than one version of Microsoft Visual C (including any C compiler not made by Microsoft). If you find them, comment away the #error line.
    • Create a separate directory structure for development. The text below assumes that this directory structure starts (for Vim) at d:\devel\vim\. Change that prefix whenever it appears below if you use something else.
    • Environment variables: The method to set them depends on your version of Windows. In my W98, I use lines with "SET NAME=value" in C:\AUTOEXEC.BAT. In NT-based systems there are menus, but they aren't very easy to find. They are accessed from the "Advanced" tab of the "System" Control Panel widget. Or if you have enabled the CMD.EXE autorun feature (see "CMD.EXE /?" -- without quotes -- for details) then you can set them from your autorun script, as in W98.
      • BOR (Only for BCC) - The base directory of the Borland compiler download (it has subdirectories BIN, LIB, INCLUDE, etc.)
      • PATH (for BCC) - Check that %BOR%\bin (or the equivalent) comes near the start of your PATH. For gcc, the cygwin path should be OK.
      • USERNAME and USERDOMAIN - check that %USERNAME%@%USERDOMAIN% means you. For instance, type 
        echo %username%@%userdomain%
        at the "Dos" prompt and look at the answer.
      • HOME and VIM - you might want to set HOME to some convenient place for your "user" files (such as your vimrc) and VIM to the parent of your "production" vim70 directory (I recommend 8.3 format, as in C:\PROGRA~1\VIM ).
      • For interpreted languages, if you use them (with the exception of PATH, which is a semicolon-separated list, the following can also be defined in the MAKE command-line, see below):
        • Perl:
          • PERL=pathname : the Perl directory
          • PERL_VER : the Perl version (default 56)
          • DYNAMIC_PERL=yes : to load the Perl DLL dynamically
          • PATH should include the equivalent of %PERL%\bin
        • Python:
          • PYTHON=pathname : the Python directory
          • PYTHON_VER : the version of Python (default 22)
          • DYNAMIC_PYTHON=yes : to load the Python DLL dynamically
          • PATH should include the %PYTHON% directory
        • Ruby:
          • RUBY=pathname : the Ruby directory
          • RUBY_VER : the Ruby version (default 16). Versions before 1.6.5 don't work.
          • RUBY_VER_LONG : the "long" Ruby version (default 1.6)
          • DYNAMIC_RUBY=yes : to load Ruby dynamically
          • PATH should include the equivalent of %RUBY%\bin
        • TCL (if you have Ruby, you can use the TCL distro that comes with it):
          • TCL=pathname : e.g., C:\PROGRA~1\ruby\tcl
          • TCL_VER : the TCL version (default 83)
          • DYNAMIC_TCL=yes : to load TCL dynamically
        • MzScheme (Vim version 7 only):
          • MZSCHEME=pathname : the MzScheme directory
          • MZSCHEME_VER : the MzScheme version (default 209_000)
          • DYNAMIC_MZSCHEME=yes : to load MzScheme dynamically
          • MSCHEME_DLLS=path : path to the MzScheme DLLs if DYNAMIC_MZSCHEME is set to "no"
  2. Once per release:
    • This section assumes Vim 7.0. Change directory names (in the obvious way) for other versions.
    • (Optional) Install the full distribution (runtime and binaries) from the "official" site. This is your "production" Vim (which you run to edit files), not your "development" one (which you compile).
    • The Vim sources: Download the full Unix sources, even for Win32. For Vim 7.0, they are in the following places:
      1. Download these three archives anywhere convenient.
      2. "Prepare" the bz2 archive by running (in cygwin) 
        bunzip2 vim-7.0.tar.bz2
        This uncompresses it, removes the .bz2 extension, and makes it understandable to WinZip.
      3. Using WinZip (or Cygwin gzip and tar), extract the three archives on top of each other into your d:\devel\vim (or whatever) directory. This creates a subdirectory "vim70" and puts evrything in or under it. [For the ".tar.gz" archives, WinZip will tell you that each of them contains only one further (.tar) archive and ask you if you want to unpack that at some temporary location and open it immediately. Answer "Yes" to that.]
    • (Optional) Download Vince Negri's patch if you want to use one or more of the 'conceal', 'cursorbind' and :ownsyntax features.
  3. Every time:
    • Note: I haven't tested all possible methods of getting the Vim bugfixes. The one described below works for me. There are (IIUC) three other methods: CVS, A-A-P (which requires Python) and Subversion. I don't know how to make them work, so don't ask me.
    1. For stable releases (7.0): Download any new patches from ftp://ftp.vim.org/pub/vim/patches/7.0/. (For unstable versions the sources may be elsewhere, usually somewhere under ftp://ftp.vim.org/pub/vim/unstable/.) Also download the latest version of the README file from the same place, it is the "table of contents" of the patches. Place all patches and their README in d:\devel\vim\vim70\patches\ (and create that directory if it doesn't exist). OTOH, if your browser or other ftp client asks permission to overwrite an existing README on your disk, click "Yes".
    2. In cygwin: 
            cd /cygdrive/d/devel/vim/vim70
      patch -p0 < patches/7.0.001
      patch -p0 < patches/7.0.002
      etc., for all new patches in ascending sequence. As you apply the patches, watch the filenames output by the patch program. For instance, if anything ending in ".vim" or ".txt" gets patched, you may want to copy (not move) the new version from the "development" hierarchy (starting at d:\devel\vim\vim70\runtime) to the "production" hierarchy (starting — in Cygwin parlance — at $VIM/vim70)
    3. If you applied patches to one or more helpfiles (i.e. runtime/doc/*.txt), then, after copying them to your "production" hierarchy (in $VIM/vim70/doc/) you will have to use the following Ex-command the next time you run (g)vim: 
      :helptags $VIMRUNTIME/doc
    4. For all versions: Have a look at the Makefile you are going to use (Make_bc5.mak for BCC32 or Make_cyg.mak for cygwin gcc). It is in the "src" subdirectory. Write down any non-standard option values you might need. Then add them in the form -Dname=value (for Borland make) or name=value (for cygwin make) on the following command-line. Here are the two commands I use to generate vim and gvim (or the ones I used when I had a Windows machine):
      • For Borland make and BCC32 (in COMMAND.COM or CMD.EXE): 
              D:
      cd \devel\vim\vim70\src
      make -B -fMake_bc5.mak -DGUI=no vim
      make -B -fMake_bc5.mak -DOLE=yes -DCPUNR=i686 vim
      • For Cygwin make and gcc (in Cygwin bash): 
              cd /cygdrive/d/devel/vim/vim70/src
      make -B -f Make_cyg.mak GUI=no vim.exe
      make -B -f Make_cyg.mak OLE=yes gvim.exe
      • A trick: To log the output of the (Cygwin) make to a file and also watch it in real-time:
              make -B -f Make_cyg.mak OLE=yes gvim.exe 2>&1 |tee gvim.log

      -B (optional) forces a full rebuild from scratch regardless of modification dates. Without it, only modified modules will be recompiled.
      GUI=no builds the console version.
      OLE=yes builds a GUI with OLE support
      CPUNR= (optional) defines the processor level. Admissible values for BCC are i386, i486, i586, i686, or 3, 4, 5, 6. For gcc, there are two variables (CPUNR and ARCH). In both cases, omitting it will assume i386, which should build an executable which works on all processors which can run Windows.
      DEBUG=yes (optional) if you want to compile "with debugging information".
      vim, vim.exe or gvim.exe is the "target". On BCC, "vim" means "build only the editor executable". On Cygwin, the exact executable name must be used. If you omit the target, Make uses a default target named "all", meaning "build the editor and all ancillary programs".
      There are other options. Mostly the defaults are OK.
    5. Watch the action while compilation goes on...
    6. Don't panic if you see many warnings, especially in if_perl.c, if_ruby.c and if_tcl.c. As long as an executable is produced, there is a good chance that it will work.
    7. The programs you just compiled end up in the current (src) directory. If you omit the target, some ancillary programs are also compiled, they may end up in src/ (install, uninstal) or under it (gvimext, xxd).
    8. Run gvim from there. Issue the ":version" command and check its output. Maybe issue a few other commands to check that it works OK. If it does:
    9. (Optional) Rename %VIM%\vim70\gvim.exe and/or \vim.exe to something.else (e.g., gvim000.exe, vim000.exe).
    10. Copy your newly-compiled editor to the "production" hierarchy, at %vim%\vim70.
    11. That's all folks ! — as far as the binaries are concerned. The "official patches" usually do not affect the runtime files, even when there are changes to them. The latest versions of the runtime files are (or ought to be) in ftp://ftp.vim.org/pub/vim/runtime/ and its subdirectories. The README.txt in that same folder tells you how to use A-A-P (and where to obtain it) to get only the new versions (except the first time, of course). Or if you don't want A-A-P (or if you don't want Python, which is required by A-A-P), you can get the runtime files by plain old ftp — but in that case you will have to do the dirty work by hand. — Note: That pub/vim/runtime/ directory has a dos/ subdirectory which contains a duplicate copy of everything but with Dos ends-of-files. I recommend not to bother with those and to use everything except the files in or under runtime/dos/. Vim for Windows can cope with Unix-like ends-of-line anyway (if you leave the 'fileformats' option at its default "dos,unix" value) and Unix fileformat uses one less byte per line of text.
Back to "The Vim Editor" Back to Welcome page