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

Re: Compiling Vim with X on Mac

Expand Messages
  • Bram Moolenaar
    [redirected from vim_use to vim_dev] ... Phew, that s a mess. I didn t expect so many dependencies. Can we think of another solution? Perhaps we can split
    Message 1 of 2 , May 27, 2011
      [redirected from vim_use to vim_dev]

      Ben Schmidt wrote:

      > >> I build with a standard toolset using ./configure and make.
      > >> NO_X11_INCLUDES is only defined in and by the two Mac-specific source
      > >> files named above. As one of the code comments says, this is to avoid a
      > >> clash between definitions of Boolean in the X11 and Mac header files.
      > >> All the actual GTK components compile with the X11 headers included (and
      > >> not any Mac headers).
      > >
      > > OK, I got confused. I think in vim.h FEAT_GUI should be defined even
      > > when NO_X11_INCLUDES is defined. If there is some place where FEAT_GUI
      > > causes trouble then add a check for NO_X11_INCLUDES there. That should
      > > be a lot cleaner an avoids unexpected side effects. NO_X11_INCLUDES
      > > suggests only the includes are skipped, nothing else.
      >
      > I agree. It is a much bigger and more complicated patch, though, as not
      > including those files has a lot of side-effects in terms of which
      > structures can be defined. I've done what I think is most sensible in
      > the attached patch. What do you think?

      Phew, that's a mess. I didn't expect so many dependencies.

      Can we think of another solution? Perhaps we can split os_macosx.c into
      a part that conflicts with the X11 headers and doesn't contain any GUI
      stuff and a part with the rest, that may use GUI stuff? Or is there
      code that both uses the GUI and conflicts with X11 headers?

      > I've checked it compiles with the GTK and MacVim GUIs (a couple of
      > clashes with MacVim's changes, but easy enough to resolve).
      >
      > I can't check with the Carbon GUI as that doesn't compile on my system
      > anyway. I'm not sure why that is. Maybe it's using APIs that are too
      > old. That raises an interestiong question: does anybody use it, and if
      > not, is the NO_X11_INCLUDES thing even necessary any more? Maybe it
      > isn't, and we could deprecate and remove the Carbon GUI entirely, and
      > get rid of these Mac-specific hacks. MacVim essentially replaces the old
      > Carbon GUI anyway.

      Well, there are older Macs around (like my old powerbook).

      > There may be a few Athena or Motif things that slipped through where a
      > NO_X11_INCLUDES check is needed but which I didn't add.
      >
      > >>> Is this already in src/INSTALLmac.txt? If not, can you add it?
      > >>
      > >> I don't think INSTALLmac.txt needs any modification. It does use
      > >> --disable-darwin to compile an X11 GUI, which I don't do (I seem to
      > >> remember that it disabled something I wanted--maybe native Mac clipboard
      > >> support--I can't remember). At any rate, it is nicer not to need to
      > >> supply it, and perhaps future Mac-specific features will rely on it that
      > >> we don't want to disable just because the GUI is GTK. So perhaps it
      > >> would be appropriate to remove --disable-darwin from INSTALLmac.txt, but
      > >> I'm unsure of exactly what the consequences are, and it's certainly not
      > >> necessary to change it.
      > >
      > > I would rather only make changes if we know what we are doing :-).
      >
      > Absolutely! If and when we have more Darwin-specific features that
      > others want/need with an X11 GUI, we can remove it. With MacVim on the
      > scene now, and getting better and better, the need for the X11 GUIs on
      > OS X is decreasing anyway.

      Yes, we don't want to spend too much time on this.

      --
      Amnesia is one of my favorite words, but I forgot what it means.

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
      \\\ an exciting new programming language -- http://www.Zimbu.org ///
      \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php
    • Ben Schmidt
      ... Good idea! ... I think that is essentially already the situation. The trouble is more that once you don t include the X11 headers, a bunch of structures,
      Message 2 of 2 , May 28, 2011
        > [redirected from vim_use to vim_dev]

        Good idea!

        >>> OK, I got confused. I think in vim.h FEAT_GUI should be defined even
        >>> when NO_X11_INCLUDES is defined. If there is some place where FEAT_GUI
        >>> causes trouble then add a check for NO_X11_INCLUDES there. That should
        >>> be a lot cleaner an avoids unexpected side effects. NO_X11_INCLUDES
        >>> suggests only the includes are skipped, nothing else.
        >>
        >> I agree. It is a much bigger and more complicated patch, though, as not
        >> including those files has a lot of side-effects in terms of which
        >> structures can be defined. I've done what I think is most sensible in
        >> the attached patch. What do you think?
        >
        > Phew, that's a mess. I didn't expect so many dependencies.
        >
        > Can we think of another solution? Perhaps we can split os_macosx.c into
        > a part that conflicts with the X11 headers and doesn't contain any GUI
        > stuff and a part with the rest, that may use GUI stuff? Or is there
        > code that both uses the GUI and conflicts with X11 headers?

        I think that is essentially already the situation. The trouble is more
        that once you don't include the X11 headers, a bunch of structures,
        which aren't particularly GUI-related (i.e. they exist in console Vim),
        such as Vim windows, syntax groups, etc., can't be defined, as they
        contain GUI-related members. And even if they are unused in the .c file
        being compiled, as they are defined in the header files, of which Vim
        has few, they are somewhat inavoidable. Without adding an extra layer of
        indirection to all these structures (to go via a pointer rather than use
        the GUI members directly, so at least the strctures can remain constant
        with or without the GUI/X11 datatypes defined), or splitting Vim's
        header files up a lot more (so it is more modular and we can pull in
        what, and only what we want/need in any given source file), we are a bit
        stuck.

        I don't think the code that conflicts with X11 headers actually does
        much, or uses many structures, so either of those approaches above could
        potentially work (well, indirection will always work, and modularisation
        could work or mostly work, and just fall back to indirection where
        necessary). But both are quite a bit of work, for little gain, IMHO.

        The current code, of course, is a bit dangerous--just turning off the
        GUI features when compiling certain source files means a whole bunch of
        structures are defined really very differently for just those files. If
        any are allocated or members past where the two versions match are used,
        things could go horribly wrong, and in a hard-to-find way. With the new
        patch I forwarded, there is at least only one such structure (which I
        reordered so that the one member that needs to be included/excluded is
        at the end, so it's as safe as possible). So at least it's better. Still
        not pretty, though.

        All depends which risks you prefer, really, as I, like you, don't think
        we should spend too much time on this.

        Ben.



        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php
      Your message has been successfully submitted and would be delivered to recipients shortly.