RE: Vim 6.1 compiling
- Thanks for the reply! I used the batch file and it worked. I am very new
to all of this. I was unable to reproduce some of the errors I had been
getting, I may have done something stupid.
I tried executing by hand one of the test.in files that was failing - it
worked fine. The problem is not a bug in vim but something else? I think
some of my problems are the unix tools I'm running on winXP.
Your batch files amaze me. I've been using a pc for a long time and never
saw a batch file that was so complicated and accomplished so much!
From: Walter Briscoe [mailto:wbriscoe@...]
Sent: Tuesday, August 27, 2002 7:06 AM
Subject: Re: Vim 6.1 compiling
In article <NLEBKBIKDNAAOCGHJKDMAELACBAA.david@...> of Fri,
23 Aug 2002 08:48:53 in , David Sanders <david@...> writes
>(cross posted on comp.editors)That's a clever trick! How do you achieve it?
->cut and paste
I use W9X and the cygwin patch.exe. Given bugs in the "UNIX for Windows"
diff.exe, I would not expect any patch.exe in it to work!
I delayed responding to this until I downloaded the patches.
ftp://ftp.vim.orq repeatedly disconnected me on Friday. This A.M., I had
less of that problem and now have a set of files.
>I am having several problems with Vim 6.1 compiling on WinXP with VC6:I would not be inclined to start from that point. You give partial URLs
>1. I attempted to apply the patches 1-159, but they try to make
>changes to files in the "runtime" directory which is not created by
>the distribution zips vim61rt.zip and vim61src.zip. The patches
and require your reader to guess at their completion. I am not inclined
to do. My suspicion is that you need an "extra" file rather than
I downloaded ftp://ftp.vim.org/pub/vim/patches/6.1.???
You can optimise this by using the 1-100 archive in place of the
I unpacked the two archives. A vim61 folder was created. I copied the
patches to that folder. I found that patch -p0 < 6.1.001 worked.
I deleted 6.1.001. To avoid a precedence problem with < in command.com,
I created p.bat to hold the following line:
patch -p0 < %1
I ran the following:
lfnfor on % long filenames in for: not needed in XP or NTX %
:: Apply each patch in turn - I had previously checked order of names.
%comspec% /c for %%? in (6.1.???) do call p.bat %%? > t.t
I checked t.t and found everything had worked.
>2. I can compile the sources without the patches (console), but itThat would not surprise me. Porting from UNIX to windoze tends to be a
>fails the "nmake test". (fatal error U1077: 'diff': return code '0x1')
nightmare. You may like to investigate specifics.
>3. When I tell it to use Perl (I have version 5.8.0) and dynamicChapter and verse?
>loading - I get an error saying dynamic loading does not work in
>versions prior to 5.6
>4. I can use the unix tarballs instead of the zips, succesfully applyWhat command do you run to produce this diagnostic?
>patches 1-159, and compile with VC6. I get a warning during compile
>(normal.c (4165) warning C4018: '>': signed/unsigned mismatch). It
I have just tried the following in vim61/src after patches 001 - 165
nmake -f Make_ivc.mak -n cfg="Vim - Win32 Debug gvim OLE" | find
"normal" > t.bat
:: t fails because oledbg does not exist. So I do
This time the compilation of normal.c was successful.
What do I have to do to produce the diagnostic? VC Service Pack level?
>also fails "nmake test" and will not allow dynamic loading of PerlChapter and Verse?
>5.8.0. The text files have the wrong CR-LF convention.
>I suggest you start by learning to build a patched vim without those
>I can succesfully use a pre-compiled binary, but I would like to make
>my own with patches applied and dynamic perl/python support built-in.
exciting extras. Then continue. I have a background activity
investigating the inability to build perl in a W9X environment and
comparing behaviour in NTX with W9X.
I use the enclosed script in W9X to download, build and load the
installation folder for vim. It is dependent on non-standard tools
bzip2, gzip, tar and sed. I use sed to map x.y in a tarball filename to
an xy foldername. You could probably do the same in cmd.exe. I try not
to whinge too much at Bram about such trivia.
I do not build ANYTHING in NTX for use with W9X because W2K is
insanitary with short filenames. For example, if a tarball contains a
file foo.bar, W2K generates a file whose W9X long filename is FOO.BAR
rather than foo.bar. (The W2K long filename is foo.bar.) This causes
grief with tools which are sensitive to filename case.