Loading ...
Sorry, an error occurred while loading the content.

Re: Make_ivc.mak subsidiary targets not $(CFG) affected.

Expand Messages
  • Walter Briscoe
    In message of Mon, 31 Mar 2003 10:20:15 in , Bram Moolenaar writes ... My first explanation did
    Message 1 of 5 , Mar 31, 2003
      In message <200303310820.h2V8KFq00581@...> of Mon, 31 Mar 2003
      10:20:15 in , Bram Moolenaar <Bram@...> writes
      >Walter Briscoe wrote:
      >[long text]
      >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
      build script.
      echo Transforming ff=unix to ff=dos where needed
      cd %vim_bld_home%\vim%nostop%\src
      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
      >> >problems.
      >> 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
      >> >changes.
      >> 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
      >> success.
      >> >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!
      Walter Briscoe
    Your message has been successfully submitted and would be delivered to recipients shortly.