This is a very simple wrapper script that started life as emacsmake, but has since morphed. Funny, that.
It allows a user to return the vim source tree back to pre-compiled condition, update from git (or mercurial), configure, make and install Vim. Changes can be made to the variables inside the script, which will help drive how Vim can be compiled and installed.
Bear in mind that all the major Linux distributions have the binary release of Vim in their repositories, and Vim is most definitely in the BSD ports tree. I’m providing vimmaker for those users that wish to have a bit of a hand compiling vim by hand, and not merely running with the defaults that are provided by those distributions of Linux and BSD.
I have also included a bash autocompletion script, although it might rely on the user having some completion scripts in place already.
First off, you’ll need to install the source code to Vim, adjust VIMCOMPILEHOME in this script
if you wish to put it somewhere else than ${HOME}/src/vim.
You can either fetch and extract a static tarball of the source to there, or you can access either the official github repository or its Mercurial mirror.
Tarballs are usually a fixed point in the stage of Vim development, but git repositories often have multiple threads of development, meaning there’s a requirement to select the correct one if you don’t simply want to use the latest available code, often labeled the master or main branch. This is always a moving target, so people often select a version branch, or perhaps a specific point in one of those branches, such as an official release point.
Tarballs are created at these points, making them useful for snapshots where nothing much will change in the future. It also means there’s no expected future additions to that development unless you make the effort to update on a regular basis.
If you grab code from the git or mercurial repositories, be aware that there are multiple branches of Vim code that you can build, so check out what’s available for compiling, select one, and you’ll be off. You will of course need to know how to use git or hg, and how to select the correct branch of Vim to compile. Vim tends to do point releases each time, so if you grab the latest point-release tarball, that’ll get you all the latest fixes—and possibly new bugs. Can’t win them all, I guess.
The vimmaker script can usually update the Vim source code if you happened to install it from the github repository or its mercurial mirror. Once you’ve done this, compile results will no longer match the newly-updated github/mercurial sources, so they’ll be removed before an update and recompile.
Because you’re compiling Vim, you can choose which libraries to compile Vim with; adjust the
VIMCONFIGPARAMS array for this. You will want to check the output of ./configure --help from
within the source directory to see what parameters are supported.
This will include choosing the place to put the compiled version of Vim, adjust VIMHOME. Note
that this is the root of the tree where the whole of Vim will eventually live, not the location of
the Vim binary itself. Usually directories will be created below this point for the libraries, the
binaries and the compiled script code to live. The usual place that is selected if you don’t specify
it would be /usr/local, just as with a lot of other configure-based build systems.
If you’re also going to compile with support for other things such as Motif, then make sure the required -dev/-devel packages are also installed. You’ll probably want to include support for interpreters such as python, perl and maybe even lua. As yet, support for mzscheme is somewhat flakey, and I can’t get it to work properly with the version I have. I’d recommend asking the Vim greybeards to see what they say. That is, after they clean up the coffee from laughing.
Settings for all of the variations that vimmaker supports is in the VIMCONFIGPARAMS* variables.
Run vimmaker -h to get a basic list of what configure settings you can pass in. There’s a basic
VIMCONFIGPARAMS if you don’t happen to select a specific version of Vim to compile.
In that case, you’ll get a gtk3 version. For other selections (Motif, etc) check VIMCONFIGPARAMSGTK2 or VIMCONFIGPARAMSNOX or VIMCONFIGPARAMSMOTIF, and alter all variables so they match for supported plugins.
Once you have compiled Vim, with whatever changes you’ve made, you’ll need to get it installed in the location you’ve chosen. If you haven’t specifically chosen a location, then Vim’s default install location will be /usr/local/bin, as it would be for most configured software. The vimmaker program can assist with this, of course. You’re probably going to need to have the ability to sudo if you use a location outside of your home directory.
Simply type in vim at the command line. That’s it. For a graphical Vim, you can use gvim, or you
can use vim -g instead. I suspect one is symlinked to the other, though I haven’t confirmed that.
At this stage, I haven’t got the foggiest idea what else I need, though I’ve already simplified this by removing the whole “execute Vim” stage, leaving that up to the normal instructions.
The usual applies to anyone who wants to report bugs, issues or even suggestions with vimmaker, check out the issues section of this project. If you want to report bugs with vim itself, go back to the Vim project page.