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

6.1b win32 VC4.2 if_ole.obj not buildable

Expand Messages
  • Walter Briscoe
    C: wfb VIM bld vim61b src vcvars42 Setting environment for using Microsoft Visual C++ 4.2 tools. C: wfb VIM bld vim61b src nmake /nologo /f Make_ivc.mak
    Message 1 of 6 , Mar 14, 2002
      C:\wfb\VIM\bld\vim61b\src> vcvars42
      Setting environment for using Microsoft Visual C++ 4.2 tools.
      C:\wfb\VIM\bld\vim61b\src> nmake /nologo /f Make_ivc.mak "CFG=Vim -
      Win32 Debug gvim OLE" | sed 3q
      NMAKE : warning U4004: too many rules for target '".\oleDbg\if_ole.obj"'
      NMAKE : fatal error U1077: 'cl.exe' : return code '0x2'
      Stop.
      cl.exe /nologo /MT /W3 /GX /Zi /Od /I ".\proto" /D "WIN32" /D
      "_DEBUG" / D "FEAT_GUI_W32" /D "FEAT_OLE" /Fo".\oleDbg/" /Fd".\oleDbg/"
      /Fd.\oleDbg/ /Fo.\o leDbg/ /c .\if_ole.cpp
      if_ole.cpp
      .\if_ole.h(68) : error C2629: unexpected 'struct DECLSPEC_UUID ('

      I will look at the "too many rules" problem once we agree what we should
      do. I see the problem is that if_ole.h is a generated file which should
      not be picked up where it is possible to regenerate it. I generated the
      file if_ole.h.1 below. It is not likely to be appropriate for VC[56].
      I have not sent a difference. It is HUGE.

      C:\wfb\VIM\bld\vim61b\src> move /y if_ole.h if_ole.h.0 > nul

      C:\wfb\VIM\bld\vim61b\src> move /y if_ole.h.1 if_ole.h > nul

      C:\wfb\VIM\bld\vim61b\src> nmake /nologo /f Make_ivc.mak "CFG=Vim -
      Win32 Debug gvim OLE" .\oleDbg\if_ole.obj
      NMAKE : warning U4004: too many rules for target '".\oleDbg\if_ole.obj"'
      cl.exe /nologo /MT /W3 /GX /Zi /Od /I ".\proto" /D "WIN32" /D
      "_DEBUG" / D "FEAT_GUI_W32" /D "FEAT_OLE" /Fo".\oleDbg/" /Fd".\oleDbg/"
      /Fd.\oleDbg/ /Fo.\o leDbg/ /c .\if_ole.cpp
      if_ole.cpp

      C:\wfb\VIM\bld\vim61b\src> move /y if_ole.h.1 if_ole.h > nul

      grep -li if_ole *.mak results in Make_bc5 Make_ivc.mak and Make_mvc.mak

      I will try to make all of them generate and work with a generated
      if_ole.h. If they can not generate one they should use a delivered file.
      I would want to put the delivered if_ole.h in a directory off src.
      oleHack springs to mind as a suitable name. A readme in that directory
      can give a health warning.

      From the microSoft line, I shall aim to work with VC[456].0.

      Is that acceptable?
      --
      Walter Briscoe
    • Bram Moolenaar
      ... Yes, the included if_ole.h should only be used when it can t be generated. Generating it is much better, since it avoids conflicts with versions. But not
      Message 2 of 6 , Mar 14, 2002
        Walter Briscoe wrote:

        > I will look at the "too many rules" problem once we agree what we should
        > do. I see the problem is that if_ole.h is a generated file which should
        > not be picked up where it is possible to regenerate it. I generated the
        > file if_ole.h.1 below. It is not likely to be appropriate for VC[56].
        > I have not sent a difference. It is HUGE.

        Yes, the included if_ole.h should only be used when it can't be
        generated. Generating it is much better, since it avoids conflicts with
        versions. But not all compilers include the tools to generate it.

        > I will try to make all of them generate and work with a generated
        > if_ole.h. If they can not generate one they should use a delivered file.
        > I would want to put the delivered if_ole.h in a directory off src.
        > oleHack springs to mind as a suitable name. A readme in that directory
        > can give a health warning.

        I think the solution should be found either by changing the makefile, or
        by making sure the timestamp of if_ole.h is older than the file it's
        generated from.

        > From the microSoft line, I shall aim to work with VC[456].0.
        >
        > Is that acceptable?

        You mean, only check the "x.0" versions of the compiler? No, MSVC 4.1,
        4.2 and 4.3 are quite different. If I'm not mistaking, 4.1 was the last
        one to support 16 bit windows applications and 4.3 introduces some new
        Win32 things.

        --
        FATHER: Did you kill all those guards?
        LAUNCELOT: Yes ... I'm very sorry ...
        FATHER: They cost fifty pounds each!
        "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

        /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
        /// Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim \\\
        \\\ Project leader for A-A-P -- http://www.a-a-p.org ///
        \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
      • Walter Briscoe
        In article of Thu, 14 Mar 2002 21:29:56 in , Bram Moolenaar writes [snip] ... You seem to have
        Message 3 of 6 , Mar 15, 2002
          In article <200203142029.g2EKTuW19015@...> of Thu, 14 Mar 2002
          21:29:56 in , Bram Moolenaar <Bram@...> writes
          [snip]
          >Yes, the included if_ole.h should only be used when it can't be
          >generated. Generating it is much better, since it avoids conflicts with
          >versions. But not all compilers include the tools to generate it.
          You seem to have missed the problem that the delivered if_ole.h is
          unsuitable for VC 4.2 and earlier. I do not YET know if an early
          if_ole.h works with later systems. I shall attempt to come up with a
          solution which is simplest and works with everything. My not having 4.3
          complicates that.

          >
          >> I will try to make all of them generate and work with a generated
          >> if_ole.h. If they can not generate one they should use a delivered file.
          >> I would want to put the delivered if_ole.h in a directory off src.
          >> oleHack springs to mind as a suitable name. A readme in that directory
          >> can give a health warning.
          >
          >I think the solution should be found either by changing the makefile, or
          >by making sure the timestamp of if_ole.h is older than the file it's
          >generated from.
          My perception is that the src directory should not contain files
          generated by tools (other than autoconf) and that any (possibly more
          than one) delivered if_ole.h should be somewhere else. Do you agree?

          >
          >> From the microSoft line, I shall aim to work with VC[456].0.
          >>
          >> Is that acceptable?
          >
          >You mean, only check the "x.0" versions of the compiler? No, MSVC 4.1,
          >4.2 and 4.3 are quite different. If I'm not mistaking, 4.1 was the last
          >one to support 16 bit windows applications and 4.3 introduces some new
          >Win32 things.
          >
          OK! I will test buildability against the Free Borland compiler,
          VC4.[012], and VC[56].0. Without access, I will not test VC4.3.
          --
          Walter Briscoe
        • Bram Moolenaar
          ... I thought that 4.2 should be able generate the file. Thus it doesn t need to be compatible with 4.2. Isn t that so? ... That s more a would be nice
          Message 4 of 6 , Mar 15, 2002
            Walter Briscoe wrote:

            > In article <200203142029.g2EKTuW19015@...> of Thu, 14 Mar 2002
            > 21:29:56 in , Bram Moolenaar <Bram@...> writes
            > [snip]
            > >Yes, the included if_ole.h should only be used when it can't be
            > >generated. Generating it is much better, since it avoids conflicts with
            > >versions. But not all compilers include the tools to generate it.
            > You seem to have missed the problem that the delivered if_ole.h is
            > unsuitable for VC 4.2 and earlier. I do not YET know if an early
            > if_ole.h works with later systems. I shall attempt to come up with a
            > solution which is simplest and works with everything. My not having 4.3
            > complicates that.

            I thought that 4.2 should be able generate the file. Thus it doesn't
            need to be compatible with 4.2. Isn't that so?

            > >> I will try to make all of them generate and work with a generated
            > >> if_ole.h. If they can not generate one they should use a delivered file.
            > >> I would want to put the delivered if_ole.h in a directory off src.
            > >> oleHack springs to mind as a suitable name. A readme in that directory
            > >> can give a health warning.
            > >
            > >I think the solution should be found either by changing the makefile, or
            > >by making sure the timestamp of if_ole.h is older than the file it's
            > >generated from.
            > My perception is that the src directory should not contain files
            > generated by tools (other than autoconf) and that any (possibly more
            > than one) delivered if_ole.h should be somewhere else. Do you agree?

            That's more a "would be nice" than a strict rule. It's mostly to avoid
            that when doing a "grep" you end up with matches in files that should
            not be edited. It's not very important, at this moment it's better not
            to change it.

            > >> From the microSoft line, I shall aim to work with VC[456].0.
            > >>
            > >> Is that acceptable?
            > >
            > >You mean, only check the "x.0" versions of the compiler? No, MSVC 4.1,
            > >4.2 and 4.3 are quite different. If I'm not mistaking, 4.1 was the last
            > >one to support 16 bit windows applications and 4.3 introduces some new
            > >Win32 things.
            > >
            > OK! I will test buildability against the Free Borland compiler,
            > VC4.[012], and VC[56].0. Without access, I will not test VC4.3.

            Good. I'm glad MS made so many (incompatible) versions to keep us busy!
            :-) I only use 4.1 and 5.0. I thought I had 4.3 but I can't find it.
            It does exists, doesn't it?

            --
            ARTHUR: Will you ask your master if he wants to join my court at Camelot?!
            GUARD #1: But then of course African swallows are not migratory.
            GUARD #2: Oh, yeah...
            GUARD #1: So they couldn't bring a coconut back anyway...
            The Quest for the Holy Grail (Monty Python)

            /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
            /// Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim \\\
            \\\ Project leader for A-A-P -- http://www.a-a-p.org ///
            \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
          • Walter Briscoe
            In article of Fri, 15 Mar 2002 11:20:21 in , Bram Moolenaar writes ... 4.2 generates a file
            Message 5 of 6 , Mar 20, 2002
              In article <200203151020.g2FAKLd00789@...> of Fri, 15 Mar 2002
              11:20:21 in , Bram Moolenaar <Bram@...> writes
              >
              >Walter Briscoe wrote:
              >
              >> In article <200203142029.g2EKTuW19015@...> of Thu, 14 Mar 2002
              >> 21:29:56 in , Bram Moolenaar <Bram@...> writes
              >> [snip]
              >> >Yes, the included if_ole.h should only be used when it can't be
              >> >generated. Generating it is much better, since it avoids conflicts with
              >> >versions. But not all compilers include the tools to generate it.
              >> You seem to have missed the problem that the delivered if_ole.h is
              >> unsuitable for VC 4.2 and earlier. I do not YET know if an early
              >> if_ole.h works with later systems. I shall attempt to come up with a
              >> solution which is simplest and works with everything. My not having 4.3
              >> complicates that.
              >
              >I thought that 4.2 should be able generate the file. Thus it doesn't
              >need to be compatible with 4.2. Isn't that so?
              4.2 generates a file which does not build with 4.[01]. It does build
              with 4.2, presumably 4.3, 5.0 and 6.0.

              >
              >> >> I will try to make all of them generate and work with a generated
              >> >> if_ole.h. If they can not generate one they should use a delivered file.
              >> >> I would want to put the delivered if_ole.h in a directory off src.
              >> >> oleHack springs to mind as a suitable name. A readme in that directory
              >> >> can give a health warning.
              >> >
              >> >I think the solution should be found either by changing the makefile, or
              >> >by making sure the timestamp of if_ole.h is older than the file it's
              >> >generated from.
              >> My perception is that the src directory should not contain files
              >> generated by tools (other than autoconf) and that any (possibly more
              >> than one) delivered if_ole.h should be somewhere else. Do you agree?
              >
              >That's more a "would be nice" than a strict rule. It's mostly to avoid
              >that when doing a "grep" you end up with matches in files that should
              >not be edited. It's not very important, at this moment it's better not
              >to change it.
              Make_ivc.mak writes src/oleDbg/if_ole.h but reads src/if_ole.h.
              I think something has to change. :)

              >
              >> >> From the microSoft line, I shall aim to work with VC[456].0.
              >> >>
              >> >> Is that acceptable?
              >> >
              >> >You mean, only check the "x.0" versions of the compiler? No, MSVC 4.1,
              >> >4.2 and 4.3 are quite different. If I'm not mistaking, 4.1 was the last
              >> >one to support 16 bit windows applications and 4.3 introduces some new
              >> >Win32 things.
              >> >
              >> OK! I will test buildability against the Free Borland compiler,
              >> VC4.[012], and VC[56].0. Without access, I will not test VC4.3.
              >
              >Good. I'm glad MS made so many (incompatible) versions to keep us busy!
              >:-) I only use 4.1 and 5.0. I thought I had 4.3 but I can't find it.
              >It does exists, doesn't it?
              >
              I found a reference to a product marketed to be compatible with
              "Visual C++ 4.3". I take it that it did exist.

              VC4.[01] and Borland C 5.5 do not seem to be able to process if_ole.idl.
              VC4.[01] will not compile if_ole.cpp - UnRegisterTypeLib is undeclared.
              If that call is preprocessed out with _MSC_VER < 1020, a .EXE is built.
              The output from VC[56].0 is incompatible with VC4.2.
              The output from VC4.2 builds with VC[56]

              At this stage I am VERY confused!

              How would I test the OLE facilities of a gvim?
              --
              Walter Briscoe
            • Bram Moolenaar
              ... The version included is apparently for 5.0, that s what I have and the produced file is equivalent. ... Why does it read src/if_ole.h? Hmm, the order for
              Message 6 of 6 , Mar 21, 2002
                Walter Briscoe wrote:

                > >I thought that 4.2 should be able generate the file. Thus it doesn't
                > >need to be compatible with 4.2. Isn't that so?
                > 4.2 generates a file which does not build with 4.[01]. It does build
                > with 4.2, presumably 4.3, 5.0 and 6.0.

                The version included is apparently for 5.0, that's what I have and the
                produced file is equivalent.

                > Make_ivc.mak writes src/oleDbg/if_ole.h but reads src/if_ole.h.
                > I think something has to change. :)

                Why does it read src/if_ole.h? Hmm, the order for finding include files
                may be tricky. Best would be to delete the src/if_ole.h file when
                generating a new one. Try this patch:

                *** ../../vim61b.029/src/Make_ivc.mak Sat Mar 9 19:42:34 2002
                --- Make_ivc.mak Thu Mar 21 20:14:27 2002
                ***************
                *** 443,448 ****
                --- 443,449 ----
                # Begin Custom Build

                "$(INTDIR)\if_ole.h" : $(SOURCE) "$(INTDIR)"
                + if exist .\if_ole.h del .\if_ole.h
                midl /out .\oleRel /iid iid_ole.c /tlb vim.tlb /proxy nul /header if_ole.h .\if_ole.idl

                # End Custom Build
                ***************
                *** 453,458 ****
                --- 454,460 ----
                # Begin Custom Build

                "$(INTDIR)\if_ole.h" : $(SOURCE) "$(INTDIR)"
                + if exist .\if_ole.h del .\if_ole.h
                midl /out .\oleDbg /iid iid_ole.c /tlb vim.tlb /proxy nul /header if_ole.h .\if_ole.idl

                # End Custom Build


                > VC4.[01] and Borland C 5.5 do not seem to be able to process if_ole.idl.
                > VC4.[01] will not compile if_ole.cpp - UnRegisterTypeLib is undeclared.

                Very well possible that this isn't supported by 4.0 and 4.1.

                > If that call is preprocessed out with _MSC_VER < 1020, a .EXE is built.
                > The output from VC[56].0 is incompatible with VC4.2.
                > The output from VC4.2 builds with VC[56]

                I can't remember which compiler needed the if_ole.h file to be included.
                If we know this, we can try out which VC to generate it with.

                --
                MICHAEL PALIN PLAYED: 1ST SOLDIER WITH A KEEN INTEREST IN BIRDS, DENNIS, MR
                DUCK (A VILLAGE CARPENTER WHO IS ALMOST KEENER THAN
                ANYONE ELSE TO BURN WITCHES), THREE-HEADED KNIGHT, SIR
                GALAHAD, KING OF SWAMP CASTLE, BROTHER MAYNARD'S ROOMATE
                "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

                /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                /// Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim \\\
                \\\ Project leader for A-A-P -- http://www.a-a-p.org ///
                \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
              Your message has been successfully submitted and would be delivered to recipients shortly.