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

Re: vim7: Make_mvc.mak

Expand Messages
  • Bram Moolenaar
    ... 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
    Message 1 of 9 , Jul 4, 2005
    • 0 Attachment
      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?

      --
      From the classified section of a city newspaper:
      Dog for sale: eats anything and is fond of children.


      /// 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 ///
    • 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 2 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 3 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 4 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 5 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 6 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.