Other Help Topics :: UCI question

Quote (lucky13 @ Jan. 30 2008,12:22)

Quote

I assume that process can be automated?

Of course. The recommended process at vim is to concatenate the patches into one patch and then apply it. Ports systems (such as in FreeBSD) run scripts to download source and patches, apply patches, then compile and install.

There are a couple other options for vim. The version in CVS is the patched version. So if anyone using CVS wants to build vim-7.1.uci, have at it. The other experimental option uses aap, which is similar to building ports. I want to look at this a little closer at this to see if it can be leveraged for compiling UCIs.
http://www.a-a-p.org/ports.html

I also figured there was some 'bs' in the implication that you were actually going through 500 patches, one by one.

Quote

I also figured there was some 'bs' in the implication that you were actually going through 500 patches, one by one.

No, 242. And not one by one. Re-read my first reply in this thread. I took the patched source from my FreeBSD partition (circa September or October), edited Makefile, compiled for Linux with prefix=/opt/vim. Here: "the beauty of FreeBSD ports -- I got every available patch."

That's what I'll do again -- use what I already have to reduce the work load. Just takes me a couple commands to do it. That's why I offered. Let me know if you change your mind and want to do it yourself your way.

The "500" was between 6.2 and 6.3; over 400 between 6.1 and 6.2 -- scroll to the end of the link below and look at the last of the 6.2 patches. The only point with that is, it could be many more patches before Bram releases vim 7.2, or it could be sooner than later. Some of those patches are for things I don't consider trivial or minor -- memory leaks, bad behavior.
ftp://ftp.vim.org/pub/vim/patches/

Quote (lucky13 @ Jan. 29 2008,14:43)

Quote

Isn't the source getting updated with the patches?

No, it's manual afaik. And from looking through the patch directory it looks like there can be over 500 between versions.

This is something I had never considered, not only with Vim but with all extensions I've built. It always seemed to me that official stable releases *should* at least update source releases with security and bug-fix patches, but I guess that was an incorrect assumption.

Quote

You can find what the vim patch level is with --version. Right now I'm using Knoppix/Debian (mix of Etch and Sid).

Code Sample

VIM - Vi IMproved 7.0 (2006 May 7, compiled Oct 10 2006 00:14:41)
Included patches: 1-122

Versioning can be kind of stupid and arbitrary sometimes, but it should be a static representation of development -- just a snapshot -- rather than one version continually being changed without anything explaining the difference between 3.1 released last week and 3.1 released this week. If each version were periodically patched or otherwise improved (or at least "changed"), shouldn't it get a new version number so developers and users could monitor any changes?

Quote (lucky13 @ Jan. 30 2008,18:42)

Quote

I also figured there was some 'bs' in the implication that you were actually going through 500 patches, one by one.

I attempted it with aap (just to see if it worked)...aap installed okay, but told me the patches file was "unavailable" (!); meanwhile, I patched anything with "memory leak" in the notes for my own use (once they're downloaded, it goes fairly quickly).

Also, using './configure --prefix=/opt/vim_7.1' didn't stop it from looking in the usr dir for help and spellcheck files.

Next Page...
original here.