Building Vim with patches
Richard Hartmann
some of you might be aware of the great work Markus Heidelberg
did: He created a git repository which syncs with the latest Vim
sources and also incorporates several useful patches[1]. You can
cherry-pick the ones you like or simply get the whole thing.
For an overview of patches, please look here [2] (not all of them
are in the git repo yet, I think).
Freely adapted from Jason Foreman, this is what you need to do:
# get the sources, etc
git clone git://repo.or.cz/vim_extended.git
cd vim_extended
# create your own branch based on stock vim source
git checkout -b custom origin/vim
# merge the patches you like, for example you could do
git merge origin/relativenumber origin/floating_point
# if you merged origin/lua, you will need to run this:
make -C src autoconf
# configure -- in this case with perl, python & ruby support
./configure --with-features=huge --enable-multibyte --enable-cscope \
--enable-perlinterp --enable-pythoninterp --enable-rubyinterp \
--prefix=/usr/local/vim_extended
# if you merged origin/lua, you will also need to append this
# (if lua is installed in /usr/local)
--enable-luainterp --with-lua-prefix=/usr/local
# build & deploy
make
su -
make install
Please note that there is no official support for this from Bram. The
patches will most likely work and they appear to do so for several
people. However, you might get unlucky and stuff breaks. At worst,
you could lose data. So please be aware of this before going down
this road.
For everyone else, this could prove quite useful.
Richard
[1] http://repo.or.cz/w/vim_extended.git
[2] http://groups.google.com/group/vim_dev/web/vim-patches?pli=1
Tony Mechelynck
> Hi all,
>
> some of you might be aware of the great work Markus Heidelberg
> did: He created a git repository which syncs with the latest Vim
> sources and also incorporates several useful patches[1]. You can
> cherry-pick the ones you like or simply get the whole thing.
> For an overview of patches, please look here [2] (not all of them
> are in the git repo yet, I think).
>
> Freely adapted from Jason Foreman, this is what you need to do:
>
>
> # get the sources, etc
> git clone git://repo.or.cz/vim_extended.git
>
> cd vim_extended
>
> # create your own branch based on stock vim source
> git checkout -b custom origin/vim
>
> # merge the patches you like, for example you could do
> git merge origin/relativenumber origin/floating_point
>
> # if you merged origin/lua, you will need to run this:
> make -C src autoconf
>
> ./configure --with-features=huge --enable-multibyte --enable-cscope \
> --enable-perlinterp --enable-pythoninterp --enable-rubyinterp \
> --prefix=/usr/local/vim_extended
>
> # if you merged origin/lua, you will also need to append this
> # (if lua is installed in /usr/local)
> --enable-luainterp --with-lua-prefix=/usr/local
>
> make
> su -
> make install
>
>
>
> Please note that there is no official support for this from Bram. The
> patches will most likely work and they appear to do so for several
> people. However, you might get unlucky and stuff breaks. At worst,
> you could lose data. So please be aware of this before going down
> this road.
> For everyone else, this could prove quite useful.
>
> Richard
>
>
> [1] http://repo.or.cz/w/vim_extended.git
> [2] http://groups.google.com/group/vim_dev/web/vim-patches?pli=1
You can also use patches even if you don't want to use gif: I build Vim
with Bill McCarthy's additional floating-point functions without the
help of any local repository other than a vim72/patches directory
containing the patches I want to use (Bill McCarthy's eval.diff, a
feature.h.diff for the features I want to set or avoid that cannot be
set via configure, and Bram's official patches, currently 7.2.001 to
7.2.040).
See my HowTo pages for details: browse to
http://users.skynet.be/antoine.mechelynck/vim/ then click one of the two
last items in the table of contents depending on whether you're on
Windows or on a Unix-like OS.
Note that if you use any unofficial patches, you ought to set the
"modified by" line accordingly. On Linux, this can be done by setting
the following (in bash) or similar:
export CONF_ARGS='--with-modified-by="Bill McCarthy (float)"'
For Windows, check whichever Vim makefile corresponds to your C compiler
for details.
Best regards,
Tony.
--
NEW ADDITION TO THE LIBRARY:
"Sally", the department's new inflatable doll, is available on a
short-term removal basis only -- please sign her out and return her
promptly to avoid extended waits. (We are still awaiting shipment of
our "Big John" doll.)
Matt Wozniski
> You can also use patches even if you don't want to use gif (sic)
Of course you can - you can do all of your programming without version
control, but why would you want to! Seriously, the idea isn't to
force people to change their ways, but to make it easier for those who
don't want to spend their time collecting patches and patching the
source themselves.
~Matt
Tony Mechelynck
Well, one reason could be that Vim SVN lags behind by a noticeable time
delay (days, sometimes weeks); another reason could be that you don't
know where to get a version of the appropriate version-control software
for your OS.
Seriously, the "patch" program is so easy to use (in most cases, after a
cd to the right directory, "patch -p0 <patchfilename" is enough,
replacing of course "patchfilename" by the patch file name, possibly
with path) that I can understand quite well that people wouldn't want to
spend their time learning how to use a particular version-control
package, especially now that (even outside of the Vim world) people
apparently can't agree on whether to use CVS, SVN, gif, Mercurial or
something else. :-P
Best regards,
Tony.
--
After I run your program, let's make love like crazed weasels, OK?
Matt Wozniski
>
> On 14/11/08 18:03, Matt Wozniski wrote:
>> On Fri, Nov 14, 2008 at 10:37 AM, Tony Mechelynck wrote:
>>> You can also use patches even if you don't want to use gif (sic)
>>
>> Of course you can - you can do all of your programming without version
>> control, but why would you want to! Seriously, the idea isn't to
>> force people to change their ways, but to make it easier for those who
>> don't want to spend their time collecting patches and patching the
>> source themselves.
>
> delay (days, sometimes weeks); another reason could be that you don't
> know where to get a version of the appropriate version-control software
> for your OS.
>
> Seriously, the "patch" program is so easy to use (in most cases, after a
> cd to the right directory, "patch -p0 <patchfilename" is enough,
> replacing of course "patchfilename" by the patch file name, possibly
> with path) that I can understand quite well that people wouldn't want to
> spend their time learning how to use a particular version-control
> package, especially now that (even outside of the Vim world) people
> apparently can't agree on whether to use CVS, SVN, gif, Mercurial or
> something else. :-P
But the "patch" invocation isn't the hard part, it's resolving the
conflicts when applying several nonstandard patches. I'm not arguing
that people should be forced to use version control, just pointing out
that in cases like these it's a valuable alternative.
~Matt
Richard Hartmann
<antoine.m...@gmail.com> wrote:
> Note that if you use any unofficial patches, you ought to set the
> "modified by" line accordingly. On Linux, this can be done by setting
> the following (in bash) or similar:
>
> export CONF_ARGS='--with-modified-by="Bill McCarthy (float)"'
Very good point, thanks. I actually looked for something like this,
but searching with TAINT (the term the Linux kernel uses for
any kernel loading _closed_ source modules) and Vim did not
yield any results.
As Matt points out, whatever works for anyone is good :)
For complete cluebies, and we all started that way, I think not
having to think about how to apply a patch is preferable, though.
But again, anyone should use what they like :)
Richard
PS: Is it possible to make git accept the fact that a changed
line in five branches should be put below each other in random
order. That way, all patches could concat CONF_ARGS for
all patch branches seperately and the end result would be a
complete patch list. Markus, can such a thing be done?
Markus Heidelberg
> > Note that if you use any unofficial patches, you ought to set the
> > "modified by" line accordingly. On Linux, this can be done by setting
> > the following (in bash) or similar:
> >
> > export CONF_ARGS='--with-modified-by="Bill McCarthy (float)"'
>
>
> PS: Is it possible to make git accept the fact that a changed
> line in five branches should be put below each other in random
> order. That way, all patches could concat CONF_ARGS for
> all patch branches seperately and the end result would be a
> complete patch list. Markus, can such a thing be done?
I don't think so, I think there is no way to avoid a conflict. However
if you solve it once, it doesn't occur the next time you merge from
these branches, only when you merge a new branch.
The master branch has already set --with-modified-by to "Vim extended",
but there is also a #define MODIFIED_BY in feature.h. What is the
difference between these two? Is this for configurations not using
configure and should be set, too?
But I don't plan on adding modified-by for each patch branch. I don't
want people using the git repository be plagued by avoidable merge
conflicts which keeps them off using it.
Markus
Markus Heidelberg
>
> On 14/11/08 18:03, Matt Wozniski wrote:
> > On Fri, Nov 14, 2008 at 10:37 AM, Tony Mechelynck wrote:
> >> You can also use patches even if you don't want to use gif (sic)
> >
> > Of course you can - you can do all of your programming without version
> > control, but why would you want to! Seriously, the idea isn't to
> > force people to change their ways, but to make it easier for those who
> > don't want to spend their time collecting patches and patching the
> > source themselves.
> >
> > ~Matt
>
> Well, one reason could be that Vim SVN lags behind by a noticeable time
> delay (days, sometimes weeks);
I only compile Vim since about one year. I'm very satisfied with the svn
repository and can't remember on a delay of over a week during this
year. Mostly it's between one and three days.
But are you really affected by each bug that you need all the fixes
immediately?
> another reason could be that you don't
> know where to get a version of the appropriate version-control software
> for your OS.
You don't really mean that, do you? It's not harder and not easier as
finding the patch program for your OS.
> Seriously, the "patch" program is so easy to use (in most cases, after a
The "John Doe" editor is so easy to use
> cd to the right directory, "patch -p0 <patchfilename" is enough,
> replacing of course "patchfilename" by the patch file name, possibly
> with path) that I can understand quite well that people wouldn't want to
> spend their time learning how to use a particular version-control
a particular editor
> package, especially now that (even outside of the Vim world) people
> apparently can't agree on whether to use CVS, SVN, gif, Mercurial or
vi, emacs
Markus
Markus Heidelberg
>
> On 14/11/08 18:03, Matt Wozniski wrote:
> > On Fri, Nov 14, 2008 at 10:37 AM, Tony Mechelynck wrote:
> >> You can also use patches even if you don't want to use gif (sic)
> >
The same typo twice or do you think that's the correct name? Matt had already
marked this spelling mistake above.
Markus
Tony Mechelynck
--with-modified-by (in configure) sets a #define MODIFIED_BY in
src/auto/config.h. However, even though on Unix-like systems it is
recommended to use configure, it is possible to do it all by hand and
compile Vim without it. You would then uncomment the line in feature.h.
Also, on Windows (when not generating Vim "for use only with Cygwin")
neither configure nor the top-level Makefile are used. Instead, there
are a number of makefiles in the src/ directory, one for each compiler
(including Make_cyg.mak when compiling for "native Windows" using Cygwin
gcc). These makefiles can set some options (such as featureset or which
interpreter interfaces to include) but you will probably have to set
MODIFIED_BY (if you want to use it) in feature.h in this case.
Anyway, the inclusion of patches does not free you from having to
"configure" your build: it's yours to decide whether you want a Tiny,
Small, ..., Big or Huge build, with or without which of MzScheme, Perl,
Python, Ruby and TCL, and so on. You should also set the "compiled-by"
line -- you can just as well set the "modified-by" at the same time.
Best regards,
Tony.
--
History has the relation to truth that theology has to religion --
i.e., none to speak of.
-- Lazarus Long
Markus Heidelberg
>
> On 15/11/08 17:50, Markus Heidelberg wrote:
> > The master branch has already set --with-modified-by to "Vim extended",
> > but there is also a #define MODIFIED_BY in feature.h. What is the
> > difference between these two? Is this for configurations not using
> > configure and should be set, too?
>
> src/auto/config.h. However, even though on Unix-like systems it is
> recommended to use configure, it is possible to do it all by hand and
> compile Vim without it. You would then uncomment the line in feature.h.
>
> Also, on Windows (when not generating Vim "for use only with Cygwin")
> neither configure nor the top-level Makefile are used. Instead, there
> are a number of makefiles in the src/ directory, one for each compiler
> (including Make_cyg.mak when compiling for "native Windows" using Cygwin
> gcc). These makefiles can set some options (such as featureset or which
> interpreter interfaces to include) but you will probably have to set
> MODIFIED_BY (if you want to use it) in feature.h in this case.
OK, thanks for the explanation. Then I'll use
#ifndef MODIFIED_BY
# define MODIFIED_BY
Markus
Richard Hartmann
<markus.h...@web.de> wrote:
> But I don't plan on adding modified-by for each patch branch. I don't
> want people using the git repository be plagued by avoidable merge
> conflicts which keeps them off using it.
Agreed. I will ask the git people if a conflict-free version is possible.
If yes, this would probably be a good idea to do. If not, the pointer to
vim_extended should suffice.
Richard
Markus Heidelberg
OK, thanks for asking, so it is possible ("union" merge driver, see
gitattributes manpage).
3 weeks ago I began reading the git doc, but due to lack of time I hadn't yet
reached the gitattributes.
However, we would only want the file(s) with the modified-by defined to use
this "union" merge driver and there only the line(s) with this content. But
after looking into the Makefile, the simle "union" driver is not what we want.
It doesn't help us to have multiple
CONF_ARGS = --with-modified-by="feature 1"
CONF_ARGS = --with-modified-by="feature 2"
among each other. We had to combine it to
CONF_ARGS = --with-modified-by="feature 1, feature 2"
We could probably do this with a custom merge driver, but this custom driver
would need manual installation of the tool (wait, or even automatically
included in the repo) and probably also manual adaption of the .git/config
file.
I'd really like this to happen all automatically if it's possible, but I'm not
sure about the configuration of the git repo for defining a custom merge
driver. Of course I could write a "git config" command into the readme
section.
Yes, it would be nice somehow to have a modified-by with a text for each
patch, but I don't think it's that important.
Markus
Richard Hartmann
<markus.h...@web.de> wrote:
> However, we would only want the file(s) with the modified-by defined to use
> this "union" merge driver and there only the line(s) with this content. But
> after looking into the Makefile, the simle "union" driver is not what we want.
> It doesn't help us to have multiple
> CONF_ARGS = --with-modified-by="feature 1"
> CONF_ARGS = --with-modified-by="feature 2"
> among each other. We had to combine it to
> CONF_ARGS = --with-modified-by="feature 1, feature 2"
You can simply concat the strings into WITH_MODIFIED_BY and then
feed that variable into CONF_ARGS.
Richard
Markus Heidelberg
Of course, but I don't want to force any habits for the master branch into the
patch branches. Someone only looking at a patch wonders why there is a new
variable WITH_MODIFIED_BY += "feature 1". I think you mean this syntax.
Probably an optional script could do it, detecting with git commands which
patches are included and automatically setting --with-modified-by and/or
MODIFIED_BY. Maybe it could be a little extension to the Makefile, only
available in the master branch.
Markus
Richard Hartmann
<markus.h...@web.de> wrote:
> Richard Hartmann, 16.11.2008:
>> On Sun, Nov 16, 2008 at 20:36, Markus Heidelberg
>> <markus.h...@web.de> wrote:
>>
>> > However, we would only want the file(s) with the modified-by defined to use
>> > this "union" merge driver and there only the line(s) with this content. But
>> > after looking into the Makefile, the simle "union" driver is not what we want.
>> > It doesn't help us to have multiple
>> > CONF_ARGS = --with-modified-by="feature 1"
>> > CONF_ARGS = --with-modified-by="feature 2"
>> > among each other. We had to combine it to
>> > CONF_ARGS = --with-modified-by="feature 1, feature 2"
>>
>> You can simply concat the strings into WITH_MODIFIED_BY and then
>> feed that variable into CONF_ARGS.
>
> Of course, but I don't want to force any habits for the master branch into the
> patch branches. Someone only looking at a patch wonders why there is a new
> variable WITH_MODIFIED_BY += "feature 1". I think you mean this syntax.
Bram, would you be OK with a change which facilitates this? It would not be
noticable to the general users (or pretty much anybody, for that matter),
would not affect the compiled binaries in any way and it might help to track
any problems from patched Vim versions in the future.
RIchard
Bram Moolenaar
Richard Hartmann wrote:
I wonder how you can do this without changing the distributed sources.
It's probably a good idea to use a mechanism like we have it for the
patches I send out. These patches always apply cleanly and still add
something to the :version output.
--
hundred-and-one symptoms of being an internet addict:
271. You collect hilarious signatures from all 250 mailing lists you
are subscribed to.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Richard Hartmann
> I wonder how you can do this without changing the distributed sources.
You can't. I was talking about the binaries, though.
> It's probably a good idea to use a mechanism like we have it for the
> patches I send out. These patches always apply cleanly and still add
> something to the :version output.
I am sure that if you suggest a scheme, it will be adopted.
Richard