In message <200303310820.h2V8KFq00581@...
> of Mon, 31 Mar 2003
10:20:15 in , Bram Moolenaar <Bram@...
>Walter Briscoe wrote:
>Hey, you really didn't have to give such a long explanation! Just
>saying "I know" would have been sufficient.
My first explanation did not work. It seemed easier to do a brain dump
to show that a lot of testing had been done! While doing so, I found the
work failed and walked away. I was using a UNIX file. :(
>I distribute all the files in Unix fileformat, because making diffs
>doesn't work otherwise. Only a few of the files need to be in DOS
>format before they can be used. Perhaps we should include a Vim script
>that does the conversion.
For a long time, I (incestuously) used Vim to do this. I think a script
which does NOT depend on Vim is better. I have the following in my own
echo Transforming ff=unix to ff=dos where needed
call 0hide Make_ivc.mak
call unix2dos 0Make_ivc.mak Make_ivc.mak
call 0hide vim16.def
call unix2dos 0vim16.def vim16.def
0hide is roughly equivalent to rename %1 0%1 && attrib +r %1
I quite like unix2dos; it is portable between COMMAND.COM and cmd.exe;
it is not as good as I would achieve with a shell script.
:: Interface is similar to that of Microsoft UNIX tools version of unix2dos
:: Default arguments are not supported, etc.
if %2[== [ for %%c in (echo goto:last) do %%c Usage %0 infile outfile
if exist %2 for %%c in (echo goto:last) do %%c %2 already exists
if not exist %1 for %%c in (echo goto:last) do %%c %1 does not exist
gzip -c %1 | gzip -acd > %2
if not exist %2 for %%c in (echo goto:last) do %%c %2 not created
>> >better to leave this Makefile alone. Only change it to fix real
>> I consider the following a real problem.
>> `nmake /f Make_ivc.mak cfg="Vim - Win32 Debug vim"` currently builds
>> Release versions of install.exe uninstall.exe and vimrun.exe. To build
>> Debug versions of those programs, one must use another Makefile or
>> work out how to do the work by hand. I believe in scripting such work
>> and having aiming towards makefiles which behave consistently.
>> Anything less than perfection is not enough once an improvement has
>> been identified.
>OK, that is a good reason.
>> >> ! CPP_PROJ= /nologo /MT /W3 /GX /I ".\proto" /D "WIN32"
>> >> # ADD CPP /nologo /MT /W3 /GX /I ".\proto" /D "WIN32" /c
>> >I'm quite sure these lines should be equal. Same remark for most other
>> See 1) below. I want to use $(CPP_PROJ) without /c so that I can use
>> lines such as
>I wasn't saying the /c should not be removed, I was saying that the "ADD
>CPP" line should probably include the same change. I thought that line
>was used by the IDE.
The change should be made in CPP_PROJ and NOT in ADD CPP. CPP_PROJ is
used in nmake command lines and /c is added there when needed; ADD CPP
lines are used by the IDE. I have not tried additional ADD CPP lines to
correspond to the nmake lines which use /c. It might work!
>> I would appreciate you (Bram) re-reading the following extract from my
>> original posting and answering the questions. I will be happy to try
>> and answer any doubts you have. If I fail to do so, we also have a
>> >3) ".\" and '"' elements removed where they caused grief.
>> >Would Bram like me to test the removability of all such string tokens as
>> >none seem to be necessary?
>My preference is to change only those things that need to be fixed. We
>don't fully understand the requirements for this Makefile, especially
>considering how it's read back into Devstudio. Better take no risk here.
I think I understand it fairly well. I remain suspicious and do broad
testing before showing any work to you.
>It's easy to break something for a specific situation (combination of
>Windows version and VC version, we can't test them all).
I think you exaggerate the difficulty. The current file is small where
it was large because I acquired an adequate understanding.
>> >4) clean rule patched to remove all files produced by the running value
>> >of CFG. Would Bram like me to make it $CFG) independent. For example,
>> >current $(VIM) is vim; current Make_ivc.mak removes vim.exe. Proposed
>> >Make_vim.exe would remove vim.exe gvim.exe etc.
>I usually delete vim*.exe by hand, even though "make clean" should do
>it. It would be nice if "make clean" only deletes files for one specific
The current "make clean" does what you seem to think should be done.
>> >5) Added batch compilation rule for .c.obj Conditional code selects
>> >unbatched rule where batched is un-supported. I had tried and failed to
>> >make this work in 2001. It had no significant difference on build time -
>> >3 seconds in 110 for VC6.0. (17 seconds in 659 on W95.) It saves writing
>> >~ 40 compilation lines to the nmake output.
>This is one thing that I would suspect might break something. I would
>leave this alone if there isn't a good reason to change it. Making the
>compilation go a few seconds faster isn't a very good reason.
50 euros to Uganda from me if you show it is broken inside 50 days; from
you otherwise? :)
>> >6) Added .c.exe implicit rule. This is used for uninstal.exe and for
>> >vimrun.exe but can't be used for
>> >install.exe : dosinst.c
>> >Would replacing install.exe by dosinst.exe be unprofitable? I tend to a
>> >hysterical aversion to such history!
>Most packages come with an "install.exe", thus we should keep that. I
>can't recall why we don't use install.c, but I'm sure there was a good
>reason for it.
I always assumed that there was an attempt to show the limited scope of
the file; I never understood why uninstal.c did not follow similar
There is a tendency to lose the thoughts behind changes due to the lack
of a version control system. I dislike the resultant fear of change.
>Please don't spend too much time on making Make_ivc.mak a very nice
By definition, it can't be a nice file; most information in it has to be
specified at least twice!
>makefile. It must work reliably, that is the main thing.
It did; it now works better!