Re: patch 7.0.198 (extra)
Patch 7.0.198 (extra) Problem:Win32: Compiler warnings. No need to generate gvim.exe.mnf. Solution: Add type casts. Use * for processorArchitecture. (George Reilly) Files: src/Make_mvc.mak, src/eval.c, src/gvim.exe.mnf, src/misc2.c This patch collides with some patches I posted earlier. I adopted my patches. They can be downloaded for a while from http://members.tcnet.ch/michaelis/vim/patches.zip With kind regards Mathias
Re: VC8 makefile patch
Hi Mike Thanks a lot for your patch. If the appropriate compiler options are applied to VC8, the make_mvc.mak script emits much less warning messages, and probably the created binary is better optimised in some manner. Alas, your patch doesn't work on my machine for three reasons: 1) I use VCExpress version to build vim. This is VC8, but there is no SDK. So I also downloaded the Windows Server 2003 R2 Platform SDK. This SDK was the newest when I downloaded it. Alas it comes with nmake version 7.00.xyz. So I have to use nmake 7.00.xyz to control VC8. Solution: make_mvc.mak should not estimate the version of the nmake utility, but of the compiler that is used. This is a little bit difficult, but since version 7.0 of the VC toolset there exists a environment variable MSVCVer which IMHO should be used when it is defined. 2) The nmake utility that comes with the Windows Server 2003 R2 Platform SDK has the version 7.00.8882. This is none of the versions that your patch is made for. Solution: This version should be added to the list of versions as long a s this list is maintained. Another problem: I have heart of a VC 7.1. But I don't know with which exact version number the related nmake tool comes. So it is doubtful if the version list should be maintained at all, or if one should better relay on the environment variable MSVCVer that can in case of need be defined manually by the user. 3) Your patch uses the operators , , = and = to compare version numbers. With my nmake-7.00.8882 this doesn't work, even if I omit the quotes around the numbers and the macros. Solution: It's a pity, but one has to work with == and !=. I have applied all the solutions mentioned above (by keeping to maintain the list of nmake versions) and can now build vim successfully. (To be honest: I HAVE to apply other patches too that I once have mailed to this list but seemed to have been ignored?). Best regards and thanks again for this patch Mathias Michaelis Patch U010 Written by Mike Williams [EMAIL PROTECTED] and Mathias Michaelis [EMAIL PROTECTED] Problem:VC8 no longer supports the /Gn processor code generation directive, and the makefile now uses link time code generation when not optimizing for space with an error message. Solution: Check version of the visual tool set and, if version is 8.0, use VC8 specific optimization options. Files: src/Make_mvc.mak *** ..\vim-7.0.000\src\Make_mvc.mak 2006-04-26 12:30:22.0 +0200 --- src\Make_mvc.mak2007-01-20 12:33:37.088265600 +0100 *** *** 320,326 --- 320,354 INTDIR=$(OBJDIR) OUTDIR=$(OBJDIR) + # Derive version of VC being used + !ifndef MSVCVER + !if $(_NMAKE_VER) == + MSVCVER = 4.0 + !endif + !if $(_NMAKE_VER) == 162 + MSVCVER = 5.0 + !endif + !if $(_NMAKE_VER) == 6.00.8168.0 + MSVCVER = 6.0 + !endif + !if $(_NMAKE_VER) == 7.00.9466 + MSVCVER = 7.0 + !endif + !if $(_NMAKE_VER) == 7.00.8882 + MSVCVER = 7.0 + !endif + !if $(_NMAKE_VER) == 8.00.50727.42 + MSVCVER = 8.0 + !endif + !endif + + # Default to VC6 (arbitrarily) if unknown + !ifndef MSVCVER + MSVCVER = 6.0 + !endif + # Convert processor ID to MVC-compatible number + !if $(MSVCVER) != 8.0 !if $(CPUNR) == i386 CPUARG = /G3 !elseif $(CPUNR) == i486 *** *** 334,339 --- 362,373 !else CPUARG = !endif + !else + # VC8 only allows specifying SSE architecture + !if $(CPUNR) == pentium4 + CPUARG = /arch:SSE2 + !endif + !endif !ifdef NODEBUG VIM = vim *** *** 344,349 --- 378,389 !else # MAXSPEED OPTFLAG = /Ox !endif + !if $(MSVCVER) == 8.0 + # Use link time code generation if not worried about size + !if $(OPTIMIZE) != SPACE + OPTFLAG = $(OPTFLAG) /GL + !endif + !endif CFLAGS = $(CFLAGS) $(OPTFLAG) -DNDEBUG $(CPUARG) RCFLAGS = $(rcflags) $(rcvars) -DNDEBUG ! ifdef USE_MSVCRT *** *** 363,369 CFLAGS = $(CFLAGS) -D_DEBUG -DDEBUG /Od RCFLAGS = $(rcflags) $(rcvars) -D_DEBUG -DDEBUG # The /fixed:no is needed for Quantify. Assume not 4.? as unsupported in VC4.0. ! ! if $(_NMAKE_VER) == LIBC = ! else LIBC = /fixed:no --- 403,409 CFLAGS = $(CFLAGS) -D_DEBUG -DDEBUG /Od RCFLAGS = $(rcflags) $(rcvars) -D_DEBUG -DDEBUG # The /fixed:no is needed for Quantify. Assume not 4.? as unsupported in VC4.0. ! ! if $(MSVCVER) == 4.0 LIBC = ! else LIBC = /fixed:no *** *** 707,712 --- 747,761 $(MZSCHEME_LIB) $(PERL_LIB) $(PYTHON_LIB) $(RUBY_LIB) \ $(TCL_LIB) $(NETBEANS_LIB) $(XPM_LIB) $(LINK_PDB) + # Report link time code generation progress if used. + !ifdef NODEBUG + !if $(MSVCVER) == 8.0 + !if $(OPTIMIZE) != SPACE + LINKARGS1 = $(LINKARGS1) /LTCG:STATUS + !endif + !endif + !endif + all: $(VIM).exe vimrun.exe install.exe uninstal.exe xxd/xxd.exe \ GvimExt/gvimext.dll
Re: VC8 makefile patch
Hi again!
I have realised that on my laptop that I am using at work there is a
nmake version 6.00.9782.0 which isn't in the version list of your
make_mvc.mak patch. I therefore definitively suggest to omit this
version list an relay solely on the MSVCVer environment variable
which should be defined since VC tool chain version 7.0. One can
force the user to define this variable with an !error directive or
one can utilize version 6.0 as standard. This may be a matter of taste.
Therefore, I suggest the patch that is attached to this email.
With kind regards
Mathias
Problem:VC8 no longer supports the /Gn processor code generation
directive, and the makefile now uses link time code
generation when not optimizing for space with an error
message.
Solution: Check version of the visual tool set and, if version is
8.0, use VC8 specific optimization options.
Files: src/Make_mvc.mak
*** ..\vim-7.0.000\src\Make_mvc.mak 2006-04-26 12:30:22.0 +0200
--- src\Make_mvc.mak2007-01-20 20:29:44.430628800 +0100
***
*** 320,326
--- 320,334
INTDIR=$(OBJDIR)
OUTDIR=$(OBJDIR)
+ # We must know the version of the visual C tool chain.
+ !ifndef MSVCVER
+ !message Environment variable MSVCVer not defined. Please set it to the
version of your
+ !message visual C tool chain. Possible values are 4.0, 5.0, 6.0, 7.0, 7.1 and
8.0.
+ !error Environment variable MSVCVer is undefined!
+ !endif
+
# Convert processor ID to MVC-compatible number
+ !if $(MSVCVER) != 8.0
!if $(CPUNR) == i386
CPUARG = /G3
!elseif $(CPUNR) == i486
***
*** 334,339
--- 342,353
!else
CPUARG =
!endif
+ !else
+ # VC8 only allows specifying SSE architecture
+ !if $(CPUNR) == pentium4
+ CPUARG = /arch:SSE2
+ !endif
+ !endif
!ifdef NODEBUG
VIM = vim
***
*** 344,349
--- 358,369
!else # MAXSPEED
OPTFLAG = /Ox
!endif
+ !if $(MSVCVER) == 8.0
+ # Use link time code generation if not worried about size
+ !if $(OPTIMIZE) != SPACE
+ OPTFLAG = $(OPTFLAG) /GL
+ !endif
+ !endif
CFLAGS = $(CFLAGS) $(OPTFLAG) -DNDEBUG $(CPUARG)
RCFLAGS = $(rcflags) $(rcvars) -DNDEBUG
! ifdef USE_MSVCRT
***
*** 363,369
CFLAGS = $(CFLAGS) -D_DEBUG -DDEBUG /Od
RCFLAGS = $(rcflags) $(rcvars) -D_DEBUG -DDEBUG
# The /fixed:no is needed for Quantify. Assume not 4.? as unsupported in
VC4.0.
! ! if $(_NMAKE_VER) ==
LIBC =
! else
LIBC = /fixed:no
--- 383,389
CFLAGS = $(CFLAGS) -D_DEBUG -DDEBUG /Od
RCFLAGS = $(rcflags) $(rcvars) -D_DEBUG -DDEBUG
# The /fixed:no is needed for Quantify. Assume not 4.? as unsupported in
VC4.0.
! ! if $(MSVCVER) == 4.0
LIBC =
! else
LIBC = /fixed:no
***
*** 707,712
--- 727,741
$(MZSCHEME_LIB) $(PERL_LIB) $(PYTHON_LIB) $(RUBY_LIB) \
$(TCL_LIB) $(NETBEANS_LIB) $(XPM_LIB) $(LINK_PDB)
+ # Report link time code generation progress if used.
+ !ifdef NODEBUG
+ !if $(MSVCVER) == 8.0
+ !if $(OPTIMIZE) != SPACE
+ LINKARGS1 = $(LINKARGS1) /LTCG:STATUS
+ !endif
+ !endif
+ !endif
+
all: $(VIM).exe vimrun.exe install.exe uninstal.exe xxd/xxd.exe \
GvimExt/gvimext.dll
***
*** 795,801
# Create a default rule for transforming .c files to .obj files in $(OUTDIR)
# Batch compilation is supported by nmake 1.62 (part of VS 5.0) and later)
! !IF $(_NMAKE_VER) ==
.c{$(OUTDIR)/}.obj:
!ELSE
.c{$(OUTDIR)/}.obj::
--- 824,830
# Create a default rule for transforming .c files to .obj files in $(OUTDIR)
# Batch compilation is supported by nmake 1.62 (part of VS 5.0) and later)
! !IF $(MSVCVER) == 4.0
.c{$(OUTDIR)/}.obj:
!ELSE
.c{$(OUTDIR)/}.obj::
***
*** 804,810
# Create a default rule for transforming .cpp files to .obj files in $(OUTDIR)
# Batch compilation is supported by nmake 1.62 (part of VS 5.0) and later)
! !IF $(_NMAKE_VER) ==
.cpp{$(OUTDIR)/}.obj:
!ELSE
.cpp{$(OUTDIR)/}.obj::
--- 833,839
# Create a default rule for transforming .cpp files to .obj files in $(OUTDIR)
# Batch compilation is supported by nmake 1.62 (part of VS 5.0) and later)
! !IF $(MSVCVER) == 4.0
.cpp{$(OUTDIR)/}.obj:
!ELSE
.cpp{$(OUTDIR)/}.obj::
Re: Paste as HTML
Hello * What is the added value of marking it as HTML on the clipboard? The added value is that you are able to paste the text into a word processing program like AbiWord, MS Word or StarWriter in a way that the HTML-Tags are not shown, but are interpreted by the word processing program in order to format the text as it would be formatted in a HTML browser. To achieve this know, I only see one way: Convert your text to HTML, then save it as HTML, open it with a web browser, copy it from here into the clipboard and paste it into a word processing program. With best regards Mathias
Re: Paste as HTML
Hello Tony To achieve this know, I only see one way: Convert your text to HTML, then save it as HTML, open it with a web browser, copy it from here into the clipboard and paste it into a word processing program. What about opening the HTML file directly as RTF in a word processor? I guess the original poster wants to insert code snippets into an already existing documentation. Regards Mathias
Re: Patch 7.0.051
Hi Bram Patch 7.0.051 (after 7.0.44) Thanks! That resolved my problem! Best regards Mathias
Re: Patch 7.0.044
Dear Bram Patch 7.0.044 Problem: Perl: setting a buffer line in another buffer may result in changing the current buffer. Solution: Properly change to the buffer to be changed. Files:src/if_perl.xs [...] Alas, if I want to compile this, I get the following output ---%--- C:\Program Files\ActivePerl\Bin\perl C:\Program Files\ActivePerl\lib\ExtUtils\xsubpp -prototypes -typemap C:\Program Files\ActivePerl\lib\ExtUtils\typemap -typemap typemap if_perl.xs if_perl.c cl -c /W3 /nologo -D_MT -MT -I. -Iproto -DHAVE_PATHDEF -DWIN32 -DFEAT_SNIFF -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_XPM_W32 -DWINVER=0x0500 -D_WIN32_WINNT=0x0500 /Fo.\ObjGOL/ /Ox -DNDEBUG /G6 -DFEAT_OLE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DGLOBAL_IME -DFEAT_MBYTE -DFEAT_GUI_W32 -DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_PERL -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\perl58.dll\ -DFEAT_HUGE /Zi /Fd.\ObjGOL/ /I C:\Program Files\ActivePerl\Lib\Core if_perl.c cl : Command line warning D9002 : ignoring unknown option '/G6' if_perl.c if_perl.xs(1075) : error C2275: 'buf_T' : illegal use of this type as an expression c:\software\vim\vim70\src\structs.h(1133) : see declaration of 'buf_T' if_perl.xs(1075) : error C2065: 'save_curbuf' : undeclared identifier if_perl.xs(1088) : warning C4047: '=' : 'buf_T *' differs in levels of indirection from 'int' if_perl.xs(1089) : warning C4047: '=' : 'buf_T *' differs in levels of indirection from 'int' if_perl.xs(1187) : error C2275: 'buf_T' : illegal use of this type as an expression c:\software\vim\vim70\src\structs.h(1133) : see declaration of 'buf_T' if_perl.xs(1200) : warning C4047: '=' : 'buf_T *' differs in levels of indirection from 'int' if_perl.xs(1201) : warning C4047: '=' : 'buf_T *' differs in levels of indirection from 'int' NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. ---%--- I inspected if_perl.xs and if_perl.c and saw that xsubpp simply removed preprocessor directives such as ! #ifdef FEAT_AUTOCMD out of the code without really make a decision between the #if or #else: Both parts were left. I then found http://perldoc.perl.org/perlxs.html#Inserting-POD%2c-Comments-and-C-Preprocessor-Directives I will make my patch to get this working With kind regards Mathias
Patch (unofficial): if_perl.xs is converted to an invalid if_perl.c file
Patch (after 7.0.44)
Problem:xsubpp simply removes the newly added directives form
if_perl.xs when converting it into if_perl.c
Solution: See
http://perldoc.perl.org/perlxs.html#Inserting-POD%2c-Comments-and-C-Preprocessor-Directives
*** ..\vim-7.0.044\src\if_perl.xs 2006-08-08 20:02:34.440876800 +0200
--- src\if_perl.xs 2006-08-08 21:07:26.287076800 +0200
***
*** 1048,1053
--- 1048,1054
}
}
+ #ifdef FEAT_AUTOCMD
void
Set(vimbuf, ...)
VIBUF vimbuf;
***
*** 1068,1102
line = SvPV(ST(i),PL_na);
if (lnum 0 lnum = vimbuf-b_ml.ml_line_count line != NULL)
{
- #ifdef FEAT_AUTOCMD
aco_save_T aco;
/* set curwin/curbuf for vimbuf and save some things */
aucmd_prepbuf(aco, vimbuf);
! #else
buf_T *save_curbuf = curbuf;
curbuf = vimbuf;
curwin-w_buffer = vimbuf;
- #endif
if (u_savesub(lnum) == OK)
{
ml_replace(lnum, (char_u *)line, TRUE);
changed_bytes(lnum, 0);
}
- #ifdef FEAT_AUTOCMD
- /* restore curwin/curbuf and a few other things */
- aucmd_restbuf(aco);
- /* Careful: autocommands may have made vimbuf invalid! */
- #else
curwin-w_buffer = save_curbuf;
curbuf = save_curbuf;
- #endif
}
}
}
void
Delete(vimbuf, ...)
VIBUF vimbuf;
--- 1069,1131
line = SvPV(ST(i),PL_na);
if (lnum 0 lnum = vimbuf-b_ml.ml_line_count line != NULL)
{
aco_save_T aco;
/* set curwin/curbuf for vimbuf and save some things */
aucmd_prepbuf(aco, vimbuf);
! if (u_savesub(lnum) == OK)
! {
! ml_replace(lnum, (char_u *)line, TRUE);
! changed_bytes(lnum, 0);
! }
!
! /* restore curwin/curbuf and a few other things */
! aucmd_restbuf(aco);
! /* Careful: autocommands may have made vimbuf invalid! */
! }
! }
! }
!
! #else
! void
! Set(vimbuf, ...)
! VIBUF vimbuf;
!
! PREINIT:
! int i;
! long lnum;
! char *line;
! PPCODE:
! if (buf_valid(vimbuf))
! {
! if (items 3)
! croak(Usage: VIBUF::Set(vimbuf, lnum, @lines));
!
! lnum = SvIV(ST(1));
! for(i = 2; i items; i++, lnum++)
! {
! line = SvPV(ST(i),PL_na);
! if (lnum 0 lnum = vimbuf-b_ml.ml_line_count line != NULL)
! {
buf_T *save_curbuf = curbuf;
curbuf = vimbuf;
curwin-w_buffer = vimbuf;
if (u_savesub(lnum) == OK)
{
ml_replace(lnum, (char_u *)line, TRUE);
changed_bytes(lnum, 0);
}
curwin-w_buffer = save_curbuf;
curbuf = save_curbuf;
}
}
}
+ #endif
+
+ #ifdef FEAT_AUTOCMD
void
Delete(vimbuf, ...)
VIBUF vimbuf;
***
*** 1130,1144
if (lnum 0 lnum = vimbuf-b_ml.ml_line_count)
{
buf_T *save_curbuf = curbuf;
- #ifdef FEAT_AUTOCMD
aco_save_T aco;
/* set curwin/curbuf for vimbuf and save some things */
aucmd_prepbuf(aco, vimbuf);
- #else
- curbuf = vimbuf;
- curwin-w_buffer = vimbuf;
- #endif
if (u_savedel(lnum, 1) == OK)
{
ml_delete(lnum, 0);
--- 1159,1168
***
*** 1146,1165
if (save_curbuf == curbuf)
check_cursor();
}
- #ifdef FEAT_AUTOCMD
/* restore curwin/curbuf and a few other things */
aucmd_restbuf(aco);
/* Careful: autocommands may have made vimbuf invalid! */
! #else
curwin-w_buffer = save_curbuf;
curbuf = save_curbuf;
- #endif
update_curbuf(VALID);
}
}
}
}
void
Append(vimbuf, ...)
VIBUF vimbuf;
--- 1170,1238
if (save_curbuf == curbuf)
check_cursor();
}
/* restore curwin/curbuf and a few other things */
aucmd_restbuf(aco);
/* Careful: autocommands may have made vimbuf invalid! */
! update_curbuf(VALID);
! }
! }
! }
! }
!
! #else
! void
! Delete(vimbuf, ...)
! VIBUF vimbuf;
!
! PREINIT:
! long
src/po/README_mvc.txt: Documentation Update
Problem:No Problem! Only some documentation is out dated. I hope this is the correct way how I communicate changes from which I think they could be helpful not only to me. If not, please show me the correct way. Thanks! Solution: This unofficial context patch. Files: src/po/README_mvc.txt *** ..\vim-7.0.000\src\po\README_mvc.txt2004-06-07 16:32:21.0 +0200 --- src\po\README_mvc.txt 2006-06-20 12:05:49.898793600 +0200 *** *** 4,19 gnu-gettext.win32, a Windows port of gettext by Franco Bez [EMAIL PROTECTED]. You can find it at: ! http://home.a-city.de/franco.bez/gettext/gettext_win32_en.html First read the README.txt file in this directory for general remarks on translating Vim messages. SETUP ! Set the enviroment variable LANGUAGE to the language code for the language you ! are translating Vim messages to. Languagde codes are typically two characters and you can find a list of them at: http://www.geocities.com/click2speak/languages.html --- 4,33 gnu-gettext.win32, a Windows port of gettext by Franco Bez [EMAIL PROTECTED]. You can find it at: ! http://people.freenet.de/franco.bez/gettext/gettext_win32_en.html First read the README.txt file in this directory for general remarks on translating Vim messages. + Another possibility is to use the gnuwin32 port of gettext. This is + recommended especially if you use already gnuwin32 tools to gunzip, bunzip, + patch etc. these files. You find the gnuwin32 version of gettext here: + + http://gnuwin32.sourceforge.net/packages/gettext.htm + + Yet another very strait forward way is to get the sources of gettext from + + http://www.gnu.org/software/gettext/gettext.html + + and build your own version of these tools. The documentation states that this + should be possible with MSVC4.0, MSVC5.0, MSVC6.0 or MSVC7.0, but you can + build it even successfully with MSVC8.0. + SETUP ! Set the environment variable LANGUAGE to the language code for the language you ! are translating Vim messages to. Language codes are typically two characters and you can find a list of them at: http://www.geocities.com/click2speak/languages.html *** *** 23,29 Advanced tab in the System control panel. Next, edit Make_mvc.mak so that GETTEXT_PATH points the binary directory of ! the intallation. CREATING A NEW TRANSLATION --- 37,43 Advanced tab in the System control panel. Next, edit Make_mvc.mak so that GETTEXT_PATH points the binary directory of ! the installation. CREATING A NEW TRANSLATION *** *** 43,49 You will also need to edit the file names in the comments in the .po file. You need to remove the absolute directory specification (which has the form c:\vim61\src\). You can do this in Vim with the following command with the ! appropriate directory specfication for where you have installed the Vim source: %s/c:\\vim61\\src\\//g --- 57,63 You will also need to edit the file names in the comments in the .po file. You need to remove the absolute directory specification (which has the form c:\vim61\src\). You can do this in Vim with the following command with the ! appropriate directory specification for where you have installed the Vim source: %s/c:\\vim61\\src\\//g *** *** 57,63 nmake -f Make_mvc.mak xx.po ! where xx is the langauge code for the language needing translations. The original .po file is copied to xx.po.orig. --- 71,77 nmake -f Make_mvc.mak xx.po ! where xx is the language code for the language needing translations. The original .po file is copied to xx.po.orig. -- Thanks a lot for the VIM Editor! Greetings Mathias
Re: Patch 7.0.027 (extra)
Bram
Patch 7.0.027 (extra)
[...]
}
if (msg.message == WM_USER)
+ {
+ MyTranslateMessage(msg)
^
c:\devel\vim\vim70\src\gui_w48.c(1669) : error C2146:
syntax error : missing ';' before identifier 'DispatchMessageA'
I know these little nasty things too good myself %-]
Thanks and best regards
Mathias
Re: Patch: Make_mvc.mak creates an empty gvim.exe.mnf file
Bram Patch Problem:Make_mvc.mak creates an empty gvim.exe.mnf file (or stops with an error message). Solution: Don't use 'echo' to create files. Use inline files instead. Files: src/Make_mvc.mak Before including this change I would have to check the file still works with old versions of MSVC. I still need to use 4.1 to be able to generate a win32s version. I have downloaded NMAKE 1.5 from http://support.microsoft.com/default.aspx?scid=kb;en-us;Q132084#appliesto and saw, that it can handle inline files too. I think NMAKE 1.5 is only a bug fix release with no additional features so NMAKE 1.4 should also handle inline files. The actual version on NMAKE is about 8.00.xxx. The method of using inline files is much more reliable than using echo, by reasons mentioned already at other places of that thread. With best regards Mathias
Re: Patch: gvimext.dll don't find MSVCR80.dll when built with VC8. No context menu entries.
Bram, George Patch 7.0.Make_GvimExt I don't have this compiler. Can someone with MSVC 2005 verify this works properly? Send me the patch and I'll try it out. Please retrieve _all_ my patches from the archive http://members.tcnet.ch/michaelis/vim/patches_vim_1.zip and pick out the ones that concern the mvc makefiles. Since only a view of my patches I published here have been discussed until now, I am afraid that the other ones could gone lost in the traffic of this list. Here is a list of all my patches so far: http://groups.yahoo.com/group/vimdev/message/43821 http://groups.yahoo.com/group/vimdev/message/43825 http://groups.yahoo.com/group/vimdev/message/43850 http://groups.yahoo.com/group/vimdev/message/43920 http://groups.yahoo.com/group/vimdev/message/43921 http://groups.yahoo.com/group/vimdev/message/43924 http://groups.yahoo.com/group/vimdev/message/43934 With best regards Mathias
Re: PC sources lacks if_sniff.c
Bram The source archive ftp://ftp.vim.org/pub/vim/pc/vim70src.zip contains the file if_sniff.h but not the corresponding source file if_sniff.c. Has this a specific reason or has if_sniff.c simply been forgotten? The Sniff interface is something extra, you need to get it from the extra archive. That's how it is. Hmmm ... 1. The extra archive mainly consists on platform specific files and on sub projects like tee, xxd or testdir. Some of the sub projects are included in the pc archive (xxd, testdir), others are not (tee). Well, for my compilations, I use tee too, but get it from the gnuwin32 project. Now, sniff.c is whether platform specific nor a sub project, but is an optional component of Vim, probably similar to fold.c. I have no big knowledge about Vim and its source, but it's not easy to me to see why sniff.c logically belongs into the extra archive, while sniff.h is in the source archive. 2. But there is a practical reason too why this item keeps me busy: If I set SNIFF=yes within Make_mvc.mak, I get an error message from the linker that a certain module could not be found. For me as a silly Windows user it needs some time to find out - that this is due to a missing file - that this file can be found in the extra archive for unix - that this is a feature and not a bug, so I must not give up Besides of this, I can't refrain to summarise my experiences like that: With the unique exception of patch.exe from gnuwin32 where I needed to apply the switch --binary, all other build tools (e.g. from Microsoft VS2005) didn't have any problems with unix style line ends (LF) instead of dos style line ends (CRLF). So it is almost easier to work with the unix .tar.gz archives than with the .zip archives that are kindly supplied for Windows and Dos users. Best regards Mathias
Re: Patch: Make_mvc.mak creates an empty gvim.exe.mnf file
Bram Patch Problem:Make_mvc.mak creates an empty gvim.exe.mnf file (or stops with an error message). Solution: Don't use 'echo' to create files. Use inline files instead. Files: src/Make_mvc.mak This has always worked just fine. When does it fail? The gvim.exe.mnf always was empty -- but as George Reilly (who made the skipt) told me, it is only used for 64-Bit Windows. On the other hand, the error message (FATAL error: echo returned '1') was only issued from time to time, depending on the commands I typed in before. However, the message appeared in a reproducible manner if I issued the nmake command from within a BATCH file. I checked the documentation of nmake from VC 8.0 (VS 2005) and from VC 6.0 to see if inline files can be handled. Since it is possible and since I can compile Vim _only_ like that, I'm pretty sure this patch facilitate the life of many users. My environment: Visual Studio 2005 Express Edition. C:cmd -version Microsoft Windows XP [Version 5.1.2600] C:nmake /? Microsoft (R) Program Maintenance Utility Version 8.00.50727.42 Copyright (C) Microsoft Corporation. All rights reserved. With best regards Mathias
Patch (unofficial): OLE SNIFF enabled gvim crashes on Windows by closing
Patch (unofficial)
Problem:OLE SNIFF enabled gvim crashes on Windows by issuing the
command :q after 10 minutes
Solution: Do translate and dispatch all messages. They may be addressed
to some thread of hidden window created by the os.
Files: src/gui_w48.c
*** ..\vim-7.0.000\src\gui_w48.c2006-05-07 16:13:02.0 +0200
--- src\gui_w48.c 2006-06-12 12:17:56.160569600 +0200
***
*** 1664,1670
--- 1664,1674
/* request is handled in normal.c */
}
if (msg.message == WM_USER)
+ {
+ MyTranslateMessage(msg);
+ DispatchMessage(msg);
return;
+ }
#endif
#ifdef MSWIN_FIND_REPLACE
Re: gvim crash after closing: gvim hanging in Windows XP Taskmanager
Hi vimmers I have some news about the crash. 1) Minimal requirement to build a gvim.exe that crashes with Microsoft Visual Studio 2005 Express Edition (VSEE): nmake -f Make_mvc.mak FEATURES=NORMAL GUI=yes OLE=yes \ MBYTE=no IME=no GIME=no SNIFF=yes CSCOPE=no \ ICONV=no GETTEXT=no POSTSCRIPT=no That means: gvim.exe has the problem only if all three following conditions are met: a) OLE=yes b) SNIFF=yes c) Close gvim.exe only after 15 minutes Sometimes, gvim seems to close properly, but in the Taskmanager one can see that gvim is yet there. 2) One can also build a huge debug version of vim and enable much more feature to let gvim show this behaviour. 3) The crash happens as follows: Within the source file src/os_mswin.c the function mch_exit() is called as soon as you press :q within gvim.exe. Now, the function UninitOLE(), defined in src/if_ole.c, called. This function calls the Windows API function OleUninitialize(), which alas never returns. I don't know how to find out where the problem is. Perhaps, there are some resources yet occupied, or some messages in a message queue of some hidden window, that leads OleUninitialize() to stop the whole program -- I'm not a specialist for such things. 4) Why does this happen only after gvim was running for 10 minutes or more? Perhaps this also depends on a time constant of the operating system: I had read somewhere that Windows unloads all 10 minutes some dlls that seam to not be in use any more. My work around: Don't use the SNIFF feature on Windows. Apropos SNIFF: The source file if_sniff.c is missing in the pc source package ftp://ftp.vim.org/pub/vim/pc/vim70src.zip. I got it from ftp://ftp.vim.org/pub/vim/extra/vim-7.0-extra.tar.gz. As mentioned in http://groups.yahoo.com/group/vimdev/message/43780, I'm not sure if that has a reason or not. Strange coincidence! With best regards Mathias
Patch (unofficial): Create PDBs and EXEs within same directory
Patch Problem:IMHO .pdb files should reside in the same directory as the corresponding .exe files so they can be distributet along with them. Solution: Change one line within src/Make_mvc.mak Files: src/Make_mvc.mak *** ..\vim-7.0.000\src\Make_mvc.mak 2006-06-04 18:09:36.210426300 +0200 --- src\Make_mvc.mak2006-06-05 19:02:19.844152000 +0200 *** *** 683,689 # on a crash (doesn't add overhead to the executable). # CFLAGS = $(CFLAGS) /Zi /Fd$(OUTDIR)/ ! LINK_PDB = /PDB:$(OUTDIR)/$(VIM).pdb -debug # -debug:full -debugtype:cv,fixup # # End extra feature include --- 683,689 # on a crash (doesn't add overhead to the executable). # CFLAGS = $(CFLAGS) /Zi /Fd$(OUTDIR)/ ! LINK_PDB = /PDB:$(VIM).pdb -debug # -debug:full -debugtype:cv,fixup # # End extra feature include -- Thanks a lot for the VIM Editor! Greetings Mathias
Patch (unofficial): Synchronize documetation of Makefile with my patched src/Make_mvc.mak (Thanks to Ylia)
Patch 7.0.Makefile Problem:IMHO .pdb files should reside in the same directory as the corresponding .exe files so they can be distributet along with them. Therefore, one of my recent patches adopted src/Make_mvc.mak to that opinion. Alas, now the top level Makefile is out of sync. Solution: Change documentation within ./Makefile (thanks to Ilya ilya at po4ta dot com) Files: ./Makefile *** ..\vim-7.0.000\Makefile 2006-05-07 14:16:24.0 +0200 --- .\Makefile 2006-06-09 17:34:43.712491200 +0200 *** *** 132,151 # - nmake -f Make_mvc.mak # - rm testdir/*.out, nmake -f Make_mvc.mak test and check the output. # - Rename the executables to vimw32.exe, xxdw32.exe. ! # - Rename ObjC/vim.pdb to vimw32.pdb. # - When building the Win32s version later, delete vimrun.exe, install.exe and # uninstal.exe. Otherwise rename executables to installw32.exe and # uninstalw32.exe. # Win32 GUI version: # - nmake -f Make_mvc.mak GUI=yes. # - move gvim.exe to here (otherwise the OLE version will overwrite it). ! # - Move ObjG/gvim.pdb to here. # - Delete vimrun.exe, install.exe and uninstall.exe. # - Copy GvimExt/gvimext.dll to here. # Win32 GUI version with OLE, PERL, TCL, PYTHON and dynamic IME: # - Run src/bigvim.bat (nmake -f Make_mvc.mak GUI=yes OLE=yes IME=yes ...) # - Rename gvim.exe to gvim_ole.exe. ! # - Rename ObjGOLYTR/gvim.pdb to gvim_ole.pdb. # - Delete install.exe and uninstall.exe. # - If building the Win32s version delete vimrun.exe. # Win32s GUI version: --- 132,151 # - nmake -f Make_mvc.mak # - rm testdir/*.out, nmake -f Make_mvc.mak test and check the output. # - Rename the executables to vimw32.exe, xxdw32.exe. ! # - Rename vim.pdb to vimw32.pdb. # - When building the Win32s version later, delete vimrun.exe, install.exe and # uninstal.exe. Otherwise rename executables to installw32.exe and # uninstalw32.exe. # Win32 GUI version: # - nmake -f Make_mvc.mak GUI=yes. # - move gvim.exe to here (otherwise the OLE version will overwrite it). ! # - Move gvim.pdb to here. # - Delete vimrun.exe, install.exe and uninstall.exe. # - Copy GvimExt/gvimext.dll to here. # Win32 GUI version with OLE, PERL, TCL, PYTHON and dynamic IME: # - Run src/bigvim.bat (nmake -f Make_mvc.mak GUI=yes OLE=yes IME=yes ...) # - Rename gvim.exe to gvim_ole.exe. ! # - Rename gvim.pdb to gvim_ole.pdb. # - Delete install.exe and uninstall.exe. # - If building the Win32s version delete vimrun.exe. # Win32s GUI version: -- Thanks a lot for the VIM Editor! Greetings Mathias
testmail
testmail
Re: All mails lost
Yakov ... That's why re-sending helps. Thanks again! Yes, I experienced that once or twice too. But this time, waiting one night didn't help, so I thought it stays like that for ever: I am receiving mails, can't reply nor unsubscribe nor influence in any way what's going on. This is why I was a little bit in panic. Excuse me! Sincerely Mathias
Re: gvim crash after closing: gvim hanging in Windows XP Taskmanager
Tony But if I invoke the Taskmanager by pressing Ctrl-Alt_Delete, then I observe a gvim zombie hanging around within the task list. If it doesn't happen when you build with Big features (and an otherwise identical configuration), then the only difference between Big and Hige is that the latter has +profile Thanks for that hint! I am doing some researches about this issue and am glad about such tips. Sincerely Mathias
Re: VS2005 linking errors with FEATURES=TINY GUI=yes OLE=yes
Hi Tony Thanks for your reply! If I compile vim on Windows XP with Microsoft Visual Studio 2005 Express Edition on the command line with nmake -f Make_mvc.mak DEBUG=yes FEATURES=TINY GUI=yes OLE=yes I get the [some] errors: I guess it's a bug; but Tiny features means barest bones, without arithmetic evaluation and without syntax highlighting. I don't recommend it. There is another bug that leads vim to crash sometimes. I will report it here as soon I can describe it in a reproducible manner. Anyway, I am trying to create a vim that is as small as possible but in spite of that has the property to crash. I hope it is easier to trace down the cause of the crash in a tiny vim than in a huge one. With best regards Mathias
VS2005 linking errors with FEATURES=TINY GUI=yes OLE=yes
Hi developers If I compile vim on Windows XP with Microsoft Visual Studio 2005 Express Edition on the command line with nmake -f Make_mvc.mak DEBUG=yes FEATURES=TINY GUI=yes OLE=yes I get the errors: ex_cmds2.obj : error LNK2019: unresolved external symbol _get_locale_val referenced in function _get_mess_env os_mswin.obj : error LNK2019: unresolved external symbol _gui_mch_dialog referenced in function _display_errors Is this a bug or isn't this configuration supported for certain reasons? Thanks for any replies! Best regards Mathias
Patch: nmake DEBUG=yes FEATURES=NORMAL GUI=yes OLE=yes fails
Patch 7.0.mswin Problem:On Windows, when gvim is built by the command nmake -f Make_mvc.mak DEBUG=yes FEATURES=NORMAL GUI=yes OLE=yes then the linker will issue the error message if_ole.obj : error LNK2019:i unresolved external symbol _MultiByteToWideChar_alloc referenced in function public: virtual long __stdcall CVim::Eval(wchar_t *,wchar_t * *) Solution: Include this function into the built also when OLE is enabled. Files: src/mswin.c *** ..\vim-7.0.000\src\os_mswin.c 2006-05-07 16:13:03.0 +0200 --- src\os_mswin.c 2006-06-04 17:38:32.981234300 +0200 *** *** 957,962 --- 957,966 return outlen; } + #endif /* FEAT_MBYTE */ + + #if defined(FEAT_MBYTE) || defined(FEAT_OLE) || defined(PROTO) + /* * Call MultiByteToWideChar() and allocate memory for the result. * Returns the result in *out[*outlen] with an extra zero appended. *** *** 977,982 --- 981,990 } } + #endif /* FEAT_MBYTE || FEAT_OLE */ + + #if defined(FEAT_MBYTE) || defined(PROTO) + /* * Call WideCharToMultiByte() and allocate memory for the result. * Returns the result in *out[*outlen] with an extra NUL appended. -- Thanks a lot for the VIM Editor Greetings Mathias
Re: Vim on Windows XP x64
Is someone working on integrating Microsoft Platform SDK / Visual C++ 2005? Yes, I do, and I already have sent some patches to this list. http://groups.yahoo.com/group/vimdev/message/43765 http://groups.yahoo.com/group/vimdev/message/43821 http://groups.yahoo.com/group/vimdev/message/43825 Please pay attention to them, I don't want to create them again. With kind regards Mathias
Patch: Make_mvc.mak can't handle path names that contain spaces
Patch Problem:Make_mvc.mak can't handle path names that contain spaces. Solution: Surround path names by quotes Files: src/Make_mvc.mak *** ..\vim-7.0.000\src\Make_mvc.mak 2006-05-31 09:13:13.607288000 +0200 --- src\Make_mvc.mak2006-05-31 10:24:17.718779200 +0200 *** *** 265,271 # you can get xpm.lib from http://iamphet.nm.ru/xpm or create it yourself XPM_OBJ = $(OBJDIR)/xpm_w32.obj XPM_DEFS = -DFEAT_XPM_W32 ! XPM_LIB = $(XPM)\lib\libXpm.lib XPM_INC = -I $(XPM)\include !endif !endif --- 265,271 # you can get xpm.lib from http://iamphet.nm.ru/xpm or create it yourself XPM_OBJ = $(OBJDIR)/xpm_w32.obj XPM_DEFS = -DFEAT_XPM_W32 ! XPM_LIB = $(XPM)\lib\libXpm.lib XPM_INC = -I $(XPM)\include !endif !endif *** *** 525,536 -DDYNAMIC_TCL_VER=\$(TCL_VER_LONG)\ TCL_OBJ = $(OUTDIR)\if_tcl.obj TCL_INC = /I $(TCL)\Include /I $(TCL) ! TCL_LIB = $(TCL)\lib\tclstub$(TCL_VER).lib !else CFLAGS = $(CFLAGS) -DFEAT_TCL TCL_OBJ = $(OUTDIR)\if_tcl.obj TCL_INC = /I $(TCL)\Include /I $(TCL) ! TCL_LIB = $(TCL)\lib\tcl$(TCL_VER)vc.lib !endif !endif --- 525,536 -DDYNAMIC_TCL_VER=\$(TCL_VER_LONG)\ TCL_OBJ = $(OUTDIR)\if_tcl.obj TCL_INC = /I $(TCL)\Include /I $(TCL) ! TCL_LIB = $(TCL)\lib\tclstub$(TCL_VER).lib !else CFLAGS = $(CFLAGS) -DFEAT_TCL TCL_OBJ = $(OUTDIR)\if_tcl.obj TCL_INC = /I $(TCL)\Include /I $(TCL) ! TCL_LIB = $(TCL)\lib\tcl$(TCL_VER)vc.lib !endif !endif *** *** 551,557 -DDYNAMIC_PYTHON_DLL=\python$(PYTHON_VER).dll\ PYTHON_LIB = /nodefaultlib:python$(PYTHON_VER).lib !else ! PYTHON_LIB = $(PYTHON)\libs\python$(PYTHON_VER).lib !endif !endif --- 551,557 -DDYNAMIC_PYTHON_DLL=\python$(PYTHON_VER).dll\ PYTHON_LIB = /nodefaultlib:python$(PYTHON_VER).lib !else ! PYTHON_LIB = $(PYTHON)\libs\python$(PYTHON_VER).lib !endif !endif *** *** 561,575 !ifndef MZSCHEME_VER MZSCHEME_VER = 205_000 !endif ! CFLAGS = $(CFLAGS) -DFEAT_MZSCHEME -I $(MZSCHEME)\include !if $(DYNAMIC_MZSCHEME) == yes !message MzScheme DLLs will be loaded dynamically CFLAGS = $(CFLAGS) -DDYNAMIC_MZSCHEME \ -DDYNAMIC_MZSCH_DLL=\libmzsch$(MZSCHEME_VER).dll\ \ -DDYNAMIC_MZGC_DLL=\libmzgc$(MZSCHEME_VER).dll\ !else ! MZSCHEME_LIB = $(MZSCHEME)\lib\msvc\libmzgc$(MZSCHEME_VER).lib \ ! $(MZSCHEME)\lib\msvc\libmzsch$(MZSCHEME_VER).lib !endif MZSCHEME_OBJ = $(OUTDIR)\if_mzsch.obj !endif --- 561,575 !ifndef MZSCHEME_VER MZSCHEME_VER = 205_000 !endif ! CFLAGS = $(CFLAGS) -DFEAT_MZSCHEME -I $(MZSCHEME)\include !if $(DYNAMIC_MZSCHEME) == yes !message MzScheme DLLs will be loaded dynamically CFLAGS = $(CFLAGS) -DDYNAMIC_MZSCHEME \ -DDYNAMIC_MZSCH_DLL=\libmzsch$(MZSCHEME_VER).dll\ \ -DDYNAMIC_MZGC_DLL=\libmzgc$(MZSCHEME_VER).dll\ !else ! MZSCHEME_LIB = $(MZSCHEME)\lib\msvc\libmzgc$(MZSCHEME_VER).lib \ ! $(MZSCHEME)\lib\msvc\libmzsch$(MZSCHEME_VER).lib !endif MZSCHEME_OBJ = $(OUTDIR)\if_mzsch.obj !endif *** *** 591,597 !endif # Is Perl installed in architecture-specific directories? ! !if exist($(PERL)\Bin\MSWin32-x86) PERL_ARCH = \MSWin32-x86 !endif --- 591,597 !endif # Is Perl installed in architecture-specific directories? ! !if exist($(PERL)\Bin\MSWin32-x86) PERL_ARCH = \MSWin32-x86 !endif *** *** 599,608 # Version-dependent stuff !if $(PERL_VER) == 55 ! PERL_LIB = $(PERL_INCDIR)\perl.lib !else PERL_DLL = perl$(PERL_VER).dll ! PERL_LIB = $(PERL_INCDIR)\perl$(PERL_VER).lib !endif CFLAGS = $(CFLAGS) -DFEAT_PERL --- 599,608 # Version-dependent stuff !if $(PERL_VER) == 55 ! PERL_LIB = $(PERL_INCDIR)\perl.lib !else PERL_DLL = perl$(PERL_VER).dll ! PERL_LIB = $(PERL_INCDIR)\perl$(PERL_VER).lib !endif CFLAGS = $(CFLAGS) -DFEAT_PERL *** *** 613,623 !undef PERL_LIB !endif ! PERL_EXE = $(PERL)\Bin$(PERL_ARCH)\perl ! PERL_INC = /I $(PERL_INCDIR) PERL_OBJ = $(OUTDIR)\if_perl.obj $(OUTDIR)\if_perlsfio.obj ! XSUBPP = $(PERL)\lib\ExtUtils\xsubpp ! XSUBPP_TYPEMAP = $(PERL)\lib\ExtUtils\typemap !endif --- 613,623 !undef PERL_LIB !endif ! PERL_EXE = $(PERL)\Bin$(PERL_ARCH)\perl ! PERL_INC = /I $(PERL_INCDIR) PERL_OBJ = $(OUTDIR)\if_perl.obj $(OUTDIR)\if_perlsfio.obj ! XSUBPP = $(PERL)\lib\ExtUtils\xsubpp ! XSUBPP_TYPEMAP = $(PERL)\lib\ExtUtils\typemap !endif *** *** 653,659 CFLAGS = $(CFLAGS) -DFEAT_RUBY RUBY_OBJ = $(OUTDIR)\if_ruby.obj RUBY_INC = /I $(RUBY)\lib\ruby\$(RUBY_VER_LONG)\$(RUBY_PLATFORM) ! RUBY_LIB = $(RUBY)\lib\$(RUBY_INSTALL_NAME).lib # Do we want to load Ruby dynamically? !if $(DYNAMIC_RUBY) == yes !message Ruby DLL will be loaded dynamically --- 653,659 CFLAGS =
Patch: gvimext.dll don't find MSVCR80.dll when built with VC8. No context menu entries.
Patch 7.0.Make_GvimExt Problem:On Windows, when GvimExt is built with Microsoft Visual Studio 2005, the context menu item Edit with vim doesn't appear in Explorer. Reason: GvimExt.dll cannot be loaded, because it is not prepared to the Windows Side by Side Components subsystem and so cannot find the C Runtime library in MSVCR80.dll. Solution: A manifest file is created by the linker. Embed it into the resources of GvimExt.dll. Files: src/GvimExt/Makefile *** ..\vim-7.0.000\src\GvimExt\Makefile 2006-05-07 16:13:00.0 +0200 --- src\GvimExt\Makefile2006-05-30 14:42:37.168430400 +0200 *** *** 19,24 --- 19,25 # $(implib) /NOLOGO -machine:$(CPU) -def:gvimext.def $** -out:gvimext.lib # $(link) $(dlllflags) -base:0x1C00 -out:$*.dll $** $(olelibsdll) shell32.lib gvimext.lib comctl32.lib gvimext.exp $(link) $(lflags) -dll -def:gvimext.def -base:0x1C00 -out:$*.dll $** $(olelibsdll) shell32.lib comctl32.lib + if exist $*.dll.manifest mt -nologo -manifest $*.dll.manifest -outputresource:$*.dll;2 gvimext.obj: gvimext.h *** *** 34,36 --- 35,38 - if exist gvimext.exp del gvimext.exp - if exist gvimext.obj del gvimext.obj - if exist gvimext.res del gvimext.res + - if exist gvimext.dll.manifest del gvimext.dll.manifest -- Thanks a lot for the GvimExt project for Windows! I appreciate it very much. Greetings Mathias
Re: Runtime error in explorer.exe when right clicking with vim70f gvimext.dll installed
Hello Vim List
I have a similar problem with the final vim 7.0, if I try to compile
it with Microsoft Visual Studio 2005 Express Edition. I don't get a
runtime error, but simply get no Edit with vim ... context menu
entries when I right-click on any file.
When I right click on a file in explorer I get an MSVC Runtime error
dialog:
msvcr80.dll is the problem, but it isn't that the dll is missing,
gvimext.dll loads it from c:\windows\system32. The problem is that
gvimext.dll is loading the dll incorrectly (according to the error
dialog). Obviously the source for gvimext.dll hasn't changed in a
while, but I believe this means that the gvimext.dll can't be built
against VC 8.0 until this problem is resolved. :/
Try copying src\GvimExt\gvimext.dll.manifest to wherever you've placed
gvimext.dll.
This was the first thing I tried. Then I checked with Dependency
Walker and saw that MSVCR80.DLL was now found. But in spite of
that: I got no context menus.
Then I tried
mt -outputresource:gvimext.dll -manifest gvimext.dll.manifest
to include the dll into the resources of gvimext.dll. That helped
nothing.
Then I tried to add a file/file session to gvimext.dll.manifest:
file name=gvimext.dll
comClass
description=VIM Editor Context Menu Handler
clsid={51EEE242-AD87-11d3-9C1E-0090278BBD99}
threadingModel=Apartment/
/file
Helped nothing, independent of running mt.exe or not.
I am searching for solutions for days now, browsed all the msdn
library, but found nothing: gvimext.dll doesn't work when linked
against MSVCR80.DLL with Visual Studio 2005 Express Edition.
The only workaround is: I have to link gvimext.dll statically
against the C runtime library. Then, gvimext.dll needs about five
times more space on disk, but like that the context menu entries
appear although I hardly can't believe it any more %-]
Thanks in advance for any suggestions or hints!
With best regards
Mathias
Patch: Make_mvc.mak creates an empty gvim.exe.mnf file
Patch Problem:Make_mvc.mak creates an empty gvim.exe.mnf file (or stops with an error message). (Suresh Govindachar) Solution: Don't use 'echo' to create files. Use inline files instead. Files: src/Make_mvc.mak *** ..\vim-7.0.000\src\Make_mvc.mak 2006-05-07 16:13:02.0 +0200 --- src\Make_mvc.mak2006-05-22 22:11:29.768449600 +0200 *** *** 963,1001 E_CFLAGS = $(E0_CFLAGS:=\) $(PATHDEF_SRC): auto ! @echo creating $(PATHDEF_SRC) ! @echo /* pathdef.c */ $(PATHDEF_SRC) ! @echo #include vim.h $(PATHDEF_SRC) ! @echo char_u *default_vim_dir = (char_u *)$(VIMRCLOC:\=\\); $(PATHDEF_SRC) ! @echo char_u *default_vimruntime_dir = (char_u *)$(VIMRUNTIMEDIR:\=\\); $(PATHDEF_SRC) ! @echo char_u *all_cflags = (char_u *)$(CC:\=\\) $(E_CFLAGS); $(PATHDEF_SRC) ! @echo char_u *all_lflags = (char_u *)$(link:\=\\) $(LINKARGS1:\=\\) $(LINKARGS2:\=\\); $(PATHDEF_SRC) ! @echo char_u *compiled_user = (char_u *)$(USERNAME); $(PATHDEF_SRC) ! @echo char_u *compiled_sys = (char_u *)$(USERDOMAIN); $(PATHDEF_SRC) gvim.exe.mnf: auto ! @echo ^?xml version=1.0 encoding=UTF-8 standalone=yes?^ $@ ! @echo ^assembly xmlns=urn:schemas-microsoft-com:asm.v1 manifestVersion=1.0^ $@ ! @echo ^assemblyIdentity $@ ! @echo processorArchitecture=$(ASSEMBLY_ARCHITECTURE) $@ ! @echo version=7.0.0.0 $@ ! @echo type=win32 $@ ! @echo name=Vim $@ ! @echo /^ $@ ! @echo ^description^Vi Improved - A Text Editor^/description^ $@ ! @echo ^dependency^ $@ ! @echo ^dependentAssembly^ $@ ! @echo ^assemblyIdentity $@ ! @echo type=win32 $@ ! @echo name=Microsoft.Windows.Common-Controls $@ ! @echo version=6.0.0.0 $@ ! @echo publicKeyToken=6595b64144ccf1df $@ ! @echo language=* $@ ! @echo processorArchitecture=$(ASSEMBLY_ARCHITECTURE) $@ ! @echo /^ $@ ! @echo ^/dependentAssembly^ $@ ! @echo ^/dependency^ $@ ! @echo ^/assembly^ $@ auto: if not exist auto/nul mkdir auto --- 963,1005 E_CFLAGS = $(E0_CFLAGS:=\) $(PATHDEF_SRC): auto ! @echo creating $@ ! @copy $@ ! /* pathdef.c */ ! #include vim.h ! char_u *default_vim_dir = (char_u *)$(VIMRCLOC:\=\\); ! char_u *default_vimruntime_dir = (char_u *)$(VIMRUNTIMEDIR:\=\\); ! char_u *all_cflags = (char_u *)$(CC:\=\\) $(E_CFLAGS); ! char_u *all_lflags = (char_u *)$(link:\=\\) $(LINKARGS1:\=\\) $(LINKARGS2:\=\\); ! char_u *compiled_user = (char_u *)$(USERNAME); ! char_u *compiled_sys = (char_u *)$(USERDOMAIN); ! gvim.exe.mnf: auto ! @copy $@ ! ?xml version=1.0 encoding=UTF-8 standalone=yes? ! assembly xmlns=urn:schemas-microsoft-com:asm.v1 manifestVersion=1.0 ! assemblyIdentity !processorArchitecture=$(ASSEMBLY_ARCHITECTURE) !version=7.0.0.0 !type=win32 !name=Vim ! / ! descriptionVi Improved - A Text Editor/description ! dependency !dependentAssembly ! assemblyIdentity !type=win32 !name=Microsoft.Windows.Common-Controls !version=6.0.0.0 !publicKeyToken=6595b64144ccf1df !language=* !processorArchitecture=$(ASSEMBLY_ARCHITECTURE) ! / !/dependentAssembly ! /dependency ! /assembly ! auto: if not exist auto/nul mkdir auto -- Thanks a lot for the VIM Editor! Greetings Mathias
