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

Re: vim7: Make_mvc.mak

Expand Messages
  • Dave Roberts
    ... After doing a cvs update I find that revision 1.16 of Make_mvc.mak no longer creates a VIM or GVIM executable when using Visual Studio.NET 2003. I get
    Message 1 of 9 , Jul 4, 2005
    • 0 Attachment
      Bram Moolenaar wrote:

      >Walter Briscoe wrote:
      >
      >
      >
      >>>>I merged Bram's latest Make_mvc.mak with my own. I have suggestions:
      >>>>
      >>>>1) +CPPFLAGS = $(CFLAGS)
      >>>>$(OBJDIR)/*.obj are implicitly built from ./*.c and ./*.cpp.
      >>>>It is possible to explicitly build ./*.obj from ./*.c with calls such as
      >>>>nmake -nologo -f Make_mvc.mak main.obj. The new line allows lines like
      >>>>nmake -nologo -f Make_mvc.mak if_ole.obj. to build in . with *.cpp.
      >>>>
      >>>>
      >>>$(CPPFLAGS) is not used. the .cpp.obj rule uses $(CFLAGS).
      >>>
      >>>
      >>The default rule for .c.obj uses CFLAGS
      >>The default rule for .cpp.obj uses CPPFLAGS
      >>The Make_mvc.mak rule for .c.obj uses CFLAGS
      >>The Make_mvc.mak rule for .cpp.obj uses CFLAGS
      >>
      >>Equating CPPFLAGS to $(CFLAGS) sorts things out.
      >>May be better to equate and use CPPFLAGS in Make_mvc.mak .cpp.obj rule.
      >>
      >>
      >
      >I don't get it. The default rule is never used. CPPFLAGS would always
      >be equal to CFLAGS. I don't see a reason to change it. Why look at the
      >default rule while we don't use it?
      >
      >
      >

      After doing a 'cvs update' I find that revision 1.16 of Make_mvc.mak no
      longer creates a VIM or GVIM executable when using Visual Studio.NET
      2003. I get the following:

      cd xxd
      nmake /NOLOGO -f Make_mvc.mak
      cl /nologo -DWIN32 xxd.c /link setargv.obj
      xxd.c
      cd ..
      cd GvimExt
      nmake /NOLOGO -f Makefile
      cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -D_X86_=1
      -DWIN32 -D_WIN32 -W3 -D_WIN32_IE=0x0400 -DWINVER=0x0400 -DFEAT_GETTEXT
      -D_MT -D_DLL -MD gvimext.cpp
      gvimext.cpp
      Rc /r -DWIN32 -D_WIN32 -DWINVER=0x0400 gvimext.rc
      lib /NOLOGO -machine:i386 -def:gvimext.def gvimext.obj
      gvimext.res -out:
      gvimext.lib
      gvimext.def(4) : warning LNK4017: DESCRIPTION statement not supported
      for the target platform; ignored
      Creating library gvimext.lib and object gvimext.exp
      link /INCREMENTAL:NO /NOLOGO -entry:_DllMainCRTStartup@12 -dll
      -base:0x1C000000 -out:gvimext.dll gvimext.obj gvimext.res ole32.lib
      uuid.lib oleaut32.lib kernel32.lib ws2_32.lib mswsock.lib advapi32.lib
      user32.lib gdi32.lib comdlg32.lib winspool.lib shell32.lib gvimext.lib
      comctl32.lib gvimext.exp
      cd ..

      (done)

      *****************
      By reverting to revision 1.15 I'm able to create the executables.

      Thanks,

      - Dave
    • Bram Moolenaar
      ... I shouldn t have removed .exe from the -out argument. I ll fix it. -- Get a life? What is the URL where it can be downloaded? /// Bram Moolenaar --
      Message 2 of 9 , Jul 4, 2005
      • 0 Attachment
        Dave Roberts wrote:

        > After doing a 'cvs update' I find that revision 1.16 of Make_mvc.mak no
        > longer creates a VIM or GVIM executable when using Visual Studio.NET
        > 2003. I get the following:

        I shouldn't have removed .exe from the -out argument. I'll fix it.

        --
        Get a life? What is the URL where it can be downloaded?

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
        \\\ Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html ///
      • Walter Briscoe
        In message of Mon, 4 Jul 2005 12:27:04 in , Bram Moolenaar writes ... Let me try again: The
        Message 3 of 9 , Jul 4, 2005
        • 0 Attachment
          In message <200507041027.j64AR46N078344@...> of Mon, 4 Jul
          2005 12:27:04 in , Bram Moolenaar <Bram@...> writes
          >
          >Walter Briscoe wrote:
          >
          >> >> I merged Bram's latest Make_mvc.mak with my own. I have suggestions:
          >> >>
          >> >> 1) +CPPFLAGS = $(CFLAGS)
          >> >> $(OBJDIR)/*.obj are implicitly built from ./*.c and ./*.cpp.
          >> >> It is possible to explicitly build ./*.obj from ./*.c with calls such as
          >> >> nmake -nologo -f Make_mvc.mak main.obj. The new line allows lines like
          >> >> nmake -nologo -f Make_mvc.mak if_ole.obj. to build in . with *.cpp.
          >> >
          >> >$(CPPFLAGS) is not used. the .cpp.obj rule uses $(CFLAGS).
          >> The default rule for .c.obj uses CFLAGS
          >> The default rule for .cpp.obj uses CPPFLAGS
          >> The Make_mvc.mak rule for .c.obj uses CFLAGS
          >> The Make_mvc.mak rule for .cpp.obj uses CFLAGS
          >>
          >> Equating CPPFLAGS to $(CFLAGS) sorts things out.
          >> May be better to equate and use CPPFLAGS in Make_mvc.mak .cpp.obj rule.
          >
          >I don't get it. The default rule is never used. CPPFLAGS would always
          >be equal to CFLAGS. I don't see a reason to change it. Why look at the
          >default rule while we don't use it?

          Let me try again:
          The default rule for .c.obj uses CFLAGS
          The Make_mvc.mak rule for .c.obj uses CFLAGS
          The default rule for .cpp.obj uses CPPFLAGS
          The Make_mvc.mak rule for .cpp.obj uses CFLAGS rather than CPPFLAGS.

          So, I can get something sensible when I decide to do, for example,
          nmake -nologo -f Make_mvc.mak buffer.obj

          Unless we make some change, I do not get anything sensible when I try
          nmake -nologo -f Make_mvc.mak if_ole.obj

          The difference is that our coding changes the effect of the .c.obj
          default rule but does not change the effect of the .cpp.obj rule.

          I made this change several weeks ago so I could generate .i files.
          The relevant extract from my script to do so is:
          nmake -nologo -a -n -f %makefile% %1.obj | sed "/^$/d;s/ */ /g;s/$/ -P -C/" >> %tfile%
          That sed script: identifies empty lines and deletes them; changes runs
          of spaces to one space; and appends " -P -C" to the generated line.

          That script already works if %1.obj is built from %1.c
          The change allows working if %1.obj is built from %1.cpp

          The change is for consistency in by-product abilities of Make_mvc.mak.
          --
          Walter Briscoe
        • Bram Moolenaar
          ... Why? Is the rule for .cpp.obj in Make_mvc.mak not used? That sounds like a bug. But I find it hard to believe, since building if_ole.obj is fine when
          Message 4 of 9 , Jul 5, 2005
          • 0 Attachment
            Walter Briscoe wrote:

            > Let me try again:
            > The default rule for .c.obj uses CFLAGS
            > The Make_mvc.mak rule for .c.obj uses CFLAGS
            > The default rule for .cpp.obj uses CPPFLAGS
            > The Make_mvc.mak rule for .cpp.obj uses CFLAGS rather than CPPFLAGS.
            >
            > So, I can get something sensible when I decide to do, for example,
            > nmake -nologo -f Make_mvc.mak buffer.obj
            >
            > Unless we make some change, I do not get anything sensible when I try
            > nmake -nologo -f Make_mvc.mak if_ole.obj

            Why? Is the rule for .cpp.obj in Make_mvc.mak not used? That sounds
            like a bug. But I find it hard to believe, since building if_ole.obj is
            fine when it's being done as part of the dependencies. It should not be
            different when it's build separately.

            > The difference is that our coding changes the effect of the .c.obj
            > default rule but does not change the effect of the .cpp.obj rule.

            The default rules are not to be used. I don't see why they would be.

            --
            hundred-and-one symptoms of being an internet addict:
            234. You started college as a chemistry major, and walk out four years
            later as an Internet provider.

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
            \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
            \\\ Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html ///
          • Walter Briscoe
            In message of Tue, 5 Jul 2005 11:29:51 in , Bram Moolenaar writes ... There is no such rule.
            Message 5 of 9 , Jul 6, 2005
            • 0 Attachment
              In message <200507050929.j659TpvL065721@...> of Tue, 5 Jul
              2005 11:29:51 in , Bram Moolenaar <Bram@...> writes
              >
              >Walter Briscoe wrote:
              >
              >> Let me try again:
              >> The default rule for .c.obj uses CFLAGS
              >> The Make_mvc.mak rule for .c.obj uses CFLAGS
              >> The default rule for .cpp.obj uses CPPFLAGS
              >> The Make_mvc.mak rule for .cpp.obj uses CFLAGS rather than CPPFLAGS.
              >>
              >> So, I can get something sensible when I decide to do, for example,
              >> nmake -nologo -f Make_mvc.mak buffer.obj
              >>
              >> Unless we make some change, I do not get anything sensible when I try
              >> nmake -nologo -f Make_mvc.mak if_ole.obj
              >
              >Why? Is the rule for .cpp.obj in Make_mvc.mak not used? That sounds
              There is no such rule. There is a .cpp{$(OUTDIR)/}.obj rule. If that
              rule used $(CPPFLAGS) where it currently uses $(CFLAGS), I would be
              happy.

              >like a bug. But I find it hard to believe, since building if_ole.obj is
              >fine when it's being done as part of the dependencies. It should not be
              >different when it's build separately.
              $(OUTDIR)/if_ole.obj, not if_ole.obj is normally built.
              Using $(CFLAGS) in .c{$(OUTDIR)/}.obj affects .c.obj
              Using $(CFLAGS) in .cpp{$(OUTDIR)/}.obj does not affect .cpp.obj
              Using $(CPPFLAGS) in .cpp{$(OUTDIR)/}.obj would affect .cpp.obj
              That would be two one-line changes; I made one. I am lazy.

              >
              >> The difference is that our coding changes the effect of the .c.obj
              >> default rule but does not change the effect of the .cpp.obj rule.
              >
              >The default rules are not to be used. I don't see why they would be.
              Symmetry.
              .c{$(OUTDIR)/}.obj is a particular transformation of .c.obj
              .cpp{$(OUTDIR)/}.obj could be the same transformation of .cpp.obj
              It costs you little; it helps me more.

              Did you not see how I generate .i files?
              My technique does not work for files such as $(OUTDIR)/if_perl.obj which
              have a specialised rule. I have not needed to make such .i files.
              If I did, I would produce a technique to make OUTDIR equal "."

              I will retain this as a private change. Delivering it is too expensive.
              --
              Walter Briscoe
            Your message has been successfully submitted and would be delivered to recipients shortly.