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

Re: building Carbon-LESS gvim on Panther

Expand Messages
  • Benji Fisher
    ... I tend to agree, provided that the system clipboard is still available as * or + . I cannot think of any other Mac features that I would want to use
    Message 1 of 8 , Nov 1, 2003
    • 0 Attachment
      On Sat, Nov 01, 2003 at 01:14:13PM -0600, Eugene Lee wrote:
      > On Sat, Nov 01, 2003 at 01:32:34PM +0100, Bram Moolenaar wrote:
      > :
      > : The question is: When compiling a Mac version of Vim without Carbon,
      > : that is suppose to run in a terminal, should we skip all the
      > : Mac-specific code? Thus compile like it's done on Unix?
      >
      > I think so. Mac OS X, at its core, is still Unix. Unless there is such
      > a thing as a Carbon-linked terminal version of Vim, and such a beast has
      > additional features over a Carbon-less terminal version of Vim, I think
      > there should always be the option to build Vim without Carbon.

      I tend to agree, provided that the system clipboard is still
      available as "* or "+ . I cannot think of any other "Mac features" that
      I would want to use while in terminal mode.

      Another thing to keep in mind: with OS X.iii (Panther), Apple
      makes X11 an install option (like the "BSD subsystem"). This means that
      a lot more users will have X11 support. I think that an X11/Carbon dual
      GUI version of vim is pretty unlikely, so it makes sense to have one
      version with X11 support (or no GUI at all, of course) and another with
      Carbon support. The X11 version would look for runtime files in
      /usr/share/local/vim and the Carbon one would carry them around inside
      the bundle.

      --Benji Fisher
    • Bram Moolenaar
      ... Feel free to produce any version you think is useful. But then please also fix any problems that pop up. We now have so many different combinations of
      Message 2 of 8 , Nov 2, 2003
      • 0 Attachment
        Benji Fisher wrote:

        > On Sat, Nov 01, 2003 at 01:14:13PM -0600, Eugene Lee wrote:
        > > On Sat, Nov 01, 2003 at 01:32:34PM +0100, Bram Moolenaar wrote:
        > > :
        > > : The question is: When compiling a Mac version of Vim without Carbon,
        > > : that is suppose to run in a terminal, should we skip all the
        > > : Mac-specific code? Thus compile like it's done on Unix?
        > >
        > > I think so. Mac OS X, at its core, is still Unix. Unless there is such
        > > a thing as a Carbon-linked terminal version of Vim, and such a beast has
        > > additional features over a Carbon-less terminal version of Vim, I think
        > > there should always be the option to build Vim without Carbon.
        >
        > I tend to agree, provided that the system clipboard is still
        > available as "* or "+ . I cannot think of any other "Mac features" that
        > I would want to use while in terminal mode.
        >
        > Another thing to keep in mind: with OS X.iii (Panther), Apple
        > makes X11 an install option (like the "BSD subsystem"). This means that
        > a lot more users will have X11 support. I think that an X11/Carbon dual
        > GUI version of vim is pretty unlikely, so it makes sense to have one
        > version with X11 support (or no GUI at all, of course) and another with
        > Carbon support. The X11 version would look for runtime files in
        > /usr/share/local/vim and the Carbon one would carry them around inside
        > the bundle.

        Feel free to produce any version you think is useful. But then please
        also fix any problems that pop up. We now have so many different
        combinations of options that I can't keep track of them.

        I'll add a --disable-darwin argument for configure. This will ignore
        the Darwin detection, thus compile Vim as if it was on Unix.

        I don't know whether the terminal version should be compiled with Darwin
        support or without. They both appear to work.

        I'll soon send out a patch, please try various combinations of features
        after that.

        --
        Biting someone with your natural teeth is "simple assault," while biting
        someone with your false teeth is "aggravated assault."
        [real standing law in Louisana, United States of America]

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
        \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
        \\\ Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html ///
      • Bram Moolenaar
        ... I have fixed that now. ... Now that I m adding a --disable-darwin configure argument, I can also check if os_macosx.c is there. If it isn t then Darwin
        Message 3 of 8 , Nov 2, 2003
        • 0 Attachment
          Eugene Lee wrote:

          > Still,
          >
          > $ ./configure --disable-gui
          > $ make
          >
          > continues to fail on the make.

          I have fixed that now.

          > : You do need to unpack the extra archive when compiling the Mac version.
          > : (*)
          >
          > I thought about this. That's why I asked here. :-)

          Now that I'm adding a --disable-darwin configure argument, I can also
          check if os_macosx.c is there. If it isn't then Darwin support will be
          automatically disabled.

          > : Perhaps you wanted to build Vim like it's done on Unix, without any Mac
          > : support? I suppose we need to add another configure argument for this.
          > : Or should disabling Carbon automatically mean that we are building a
          > : pure Unix version, without any Mac-specific code?
          >
          > Yes. I've been able to do this with previous builds of Vim. I'd like
          > to see this continue. The reason is that previous Carbon builds
          > (haven't played with the 6.2.x builds) are slower than the equivalent
          > X11 gvim in visual areas like syntax highlighting & window refreshing.

          You can already build with X11 by giving a --with-x argument to
          configure. It's explained in the Makefile.

          > : The question is: When compiling a Mac version of Vim without Carbon,
          > : that is suppose to run in a terminal, should we skip all the
          > : Mac-specific code? Thus compile like it's done on Unix?
          >
          > I think so. Mac OS X, at its core, is still Unix. Unless there is such
          > a thing as a Carbon-linked terminal version of Vim, and such a beast has
          > additional features over a Carbon-less terminal version of Vim, I think
          > there should always be the option to build Vim without Carbon.

          Unfortunately, Darwin is not completely Unix. For example, resource
          forks in files can only be handled by Darwin code. And the compiler is
          different, the precompiled header warnings are sometimes annoying.

          > : I removed the define of FEAT_GUI_MAC from vim.h and then building Vim
          > : worked fine. This define should be moved to the Makefile, like it's
          > : done for other GUIs.
          >
          > Very cool! I appreciate you looking into this. Can't wait for the
          > offical patch. :-)

          I'll send it out shortly, so that we can find the next problem.

          The other methods for compiling Vim on the Mac will have to add
          FEAT_GUI_MAC to their build commands.

          --
          Snoring is prohibited unless all bedroom windows are closed and securely
          locked.
          [real standing law in Massachusetts, United States of America]

          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
          /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
          \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
          \\\ Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html ///
        • Rain Dog
          ... % sudo fixPrecomps should take care of those warnings. (Thanks to macosxhints.com for this tip.)
          Message 4 of 8 , Nov 9, 2003
          • 0 Attachment
            On Sunday, November 2, 2003, at 04:32 AM, Bram Moolenaar wrote:

            > Unfortunately, Darwin is not completely Unix. For example, resource
            > forks in files can only be handled by Darwin code. And the compiler is
            > different, the precompiled header warnings are sometimes annoying.

            % sudo fixPrecomps

            should take care of those warnings. (Thanks to macosxhints.com for
            this tip.)
          • Bram Moolenaar
            ... Thanks for reporting the solution. Perhaps we should suggest Apple to include this hint in the long list of warnings? -- Your company is doomed if your
            Message 5 of 8 , Nov 10, 2003
            • 0 Attachment
              Rain Dog wrote:

              > On Sunday, November 2, 2003, at 04:32 AM, Bram Moolenaar wrote:
              >
              > > Unfortunately, Darwin is not completely Unix. For example, resource
              > > forks in files can only be handled by Darwin code. And the compiler is
              > > different, the precompiled header warnings are sometimes annoying.
              >
              > % sudo fixPrecomps
              >
              > should take care of those warnings. (Thanks to macosxhints.com for
              > this tip.)

              Thanks for reporting the solution.

              Perhaps we should suggest Apple to include this hint in the long list of
              warnings?

              --
              Your company is doomed if your primary product is overhead transparencies.
              (Scott Adams - The Dilbert principle)

              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
              /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
              \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
              \\\ Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html ///
            Your message has been successfully submitted and would be delivered to recipients shortly.