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

Re: macvim OS X 10.9 Mavericks build

Expand Messages
  • björn
    ... Usually the AvailabilityMacros.h header gets included when you pull in a Carbon/Cocoa header - it would be good to know why this is problem is showing up
    Message 1 of 43 , Jul 8, 2013
    • 0 Attachment
      On Sat, Jun 29, 2013 at 12:28 AM, Jimmy Zelinskie wrote:
      On Friday, June 28, 2013 2:33:19 AM UTC-4, björn wrote:
      > On Thu, Jun 27, 2013 at 10:01 PM, Jimmy Zelinskie wrote:
      >
      > > As per the discussion at https://github.com/mxcl/homebrew/pull/20831#discussion_r4917643
      >
      > >
      >
      > > The required macro MAC_OS_X_VERSION_MAX_ALLOWED requires
      >
      > > AvailabilityMacros.h to be defined. This diff is all that's required upstream, the rest is brew specific:
      >
      > >
      >
      > > diff --git a/src/os_unix.c b/src/os_unix.c
      >
      > > index bb4c10e..00d9728 100644
      >
      > > --- a/src/os_unix.c
      >
      > > +++ b/src/os_unix.c
      >
      > > @@ -18,6 +18,10 @@
      >
      > >   * changed beyond recognition.
      >
      > >   */
      >
      > >
      >
      > > +#if defined(__APPLE__)
      >
      > > +#include <AvailabilityMacros.h>
      >
      > > +#endif
      >
      > > +
      >
      > >  /*
      >
      > >   * Some systems have a prototype for select() that has (int *) instead of
      >
      > >   * (fd_set *), which is wrong. This define removes that prototype. We define
      >
      > >
      >
      > > --
      >
      > > --
      >
      >
      >
      > Thanks for the patch.
      >
      >
      >
      > What is the reason that we have to pollute os_unix.c (which has
      >
      > nothing to do with OS X) with an OS X-only header?
      >
      >
      >
      > What exact problem does this patch address and is there perhaps a
      >
      > better way to solve it?
      >
      >
      >
      > Björn

      I agree -- this was just the patch located at the bottom of the pull request on the homebrew issue tracker. Vim builds if you place the #include in os_mac.h

      On Friday, June 28, 2013 5:05:03 PM UTC-4, Bram Moolenaar wrote:
      > Jimmy Zelinskie wrote:
      >
      >
      >
      > > As per the discussion at https://github.com/mxcl/homebrew/pull/20831#discussion_r4917643
      >
      > >
      >
      > > The required macro MAC_OS_X_VERSION_MAX_ALLOWED requires
      >
      > > AvailabilityMacros.h to be defined. This diff is all that's required upstream, the rest is brew specific:
      >
      > >
      >
      > > diff --git a/src/os_unix.c b/src/os_unix.c
      >
      > > index bb4c10e..00d9728 100644
      >
      > > --- a/src/os_unix.c
      >
      > > +++ b/src/os_unix.c
      >
      > > @@ -18,6 +18,10 @@
      >
      > >   * changed beyond recognition.
      >
      > >   */
      >
      > >
      >
      > > +#if defined(__APPLE__)
      >
      > > +#include <AvailabilityMacros.h>
      >
      > > +#endif
      >
      > > +
      >
      > >  /*
      >
      > >   * Some systems have a prototype for select() that has (int *) instead of
      >
      > >   * (fd_set *), which is wrong. This define removes that prototype. We define
      >
      >
      >
      > So, on what systems is AvailabilityMacros.h available?
      >
      >
      >
      > Isn't this a chicken-egg problem?
      >
      >
      >
      > --
      >
      > Veni, Vidi, Video -- I came, I saw, I taped what I saw.
      >
      >
      >
      >  /// 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    ///

      This documentation[1] leads me to believe that OSX 10.2+ supports it. This homebrew pull request[2] cites that it has been built successfully on 10.8.4-x86_64 and 10.7.5-i386.

      [1] http://wiki.herzbube.ch/index.php/Mac_OS_X_Programming#Availability_Macros
      [2] https://github.com/mxcl/homebrew/pull/20473#issuecomment-19434950

      Usually the AvailabilityMacros.h header gets included when you pull in a Carbon/Cocoa header - it would be good to know why this is problem is showing up on 10.9 but nowhere else (or does it?).

      On the other hand, placing the include at the top of os_mac.h should be harmless as this header should be present when building on a Mac.

      At the moment I don't think it is urgent to patch this, since 10.9 has not yet been publicly released, but if somebody with access to 10.9 took a closer look it would certainly be helpful (as I probably won't get 10.9 myself for a long time).

      Björn

      --
      --
      You received this message from the "vim_mac" 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
       
      ---
      You received this message because you are subscribed to the Google Groups "vim_mac" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_mac+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
       
       
    • Bram Moolenaar
      ... Then configure wouldn t find it. So one #ifdef would be sufficient. So, these version checks only make sense when not using the configure defined symbol
      Message 43 of 43 , Nov 2, 2013
      • 0 Attachment
        Felix Buenemann wrote:

        > Am 02.11.2013 um 23:40 schrieb Bram Moolenaar <Bram@...>:
        > > Kazunobu Kuriyama wrote:
        > >> On Nov 3, 2013, at 6:09 AM, Bram Moolenaar <Bram@...> wrote:
        > >>>
        > >>> Felix Buenemann wrote:
        > >>>> Am 01.11.2013 um 08:27 schrieb Kazunobu Kuriyama <kazunobu.kuriyama@...>:
        > >>>>> On Nov 1, 2013, at 12:47 PM, Bram Moolenaar <Bram@...> wrote:
        > >>>>>>
        > >>>>>> Felix Buenemann wrote:
        > >>>>>>> Am 27.10.2013 um 16:02 schrieb Bram Moolenaar <Bram@...>:
        > >>>>>>>> Björn wrote:
        > >>>>>>>>> On Mon, Oct 21, 2013 at 12:14 AM, Felix Buenemann wrote:
        > >>>>>>>>>> Am 19.10.2013 um 18:54 schrieb björn:
        > >>>>>>>>>>> On Sun, Oct 13, 2013 at 11:16 PM, Felix Bünemann wrote:
        > >>>>>>>>>>>> Am Mittwoch, 9. Oktober 2013 20:25:49 UTC+2 schrieb björn:
        > >>>>>>>>>>>>> On Wed, Oct 9, 2013 at 12:18 AM, Felix Bünemann wrote:
        > >>>>>>>>>>>>>> I'm pretty sure that AvailabilityMacros.h is available on all versions of OS
        > >>>>>>>>>>>>>> X, because it's copyright header states 2001-20xx which matches the OS X
        > >>>>>>>>>>>>>> 10.0 release timeline. Is the os_mac.h code also targeting OS 9? In that
        > >>>>>>>>>>>>>> case we should add a configure check.
        > >>>>>>>>>>>>>
        > >>>>>>>>>>>>> Yes, pre-OS X should be supported. If there is a suitable #ifdef
        > >>>>>>>>>>>>> check for that, then it should be possible to submit as a patch to
        > >>>>>>>>>>>>> mainline Vim.
        > >>>>>>>>>>>>
        > >>>>>>>>>>>> OK, I've updated the patch with a configure check:
        > >>>>>>>>>>>> https://gist.github.com/felixbuenemann/6150257
        > >>>>>>>>>>>
        > >>>>>>>>>>> This looks good to me ... but should we perhaps be checking for
        > >>>>>>>>>>> "Availability.h" instead as that is what is used on Mavericks (and
        > >>>>>>>>>>> earlier OS X versions did not need explicit inclusion of
        > >>>>>>>>>>> AvailabilityMacros.h)?
        > >>>>>>>>>>
        > >>>>>>>>>> The macros used in the vim codebase are defined in AvailabilityMacros.h not Availability.h.
        > >>>>>>>>>> Availability.h has similar but not the same macros, so using it would require cluttering the code with even more ifdefs.
        > >>>>>>>>>
        > >>>>>>>>> OK. Well, then I think this solves the problem of compiling on OS X
        > >>>>>>>>> 10.9 neatly and that it could be included in mainline Vim.
        > >>>>>>>>>
        > >>>>>>>>> Bram, can you please consider this patch for inclusion. It should
        > >>>>>>>>> apply cleanly (I just tried myself) and it automatically solves the
        > >>>>>>>>> problem of us having to know exactly when this header was made
        > >>>>>>>>> available. I've pasted it below for your convenience. Note that
        > >>>>>>>>> Felix Bünemann wrote the patch, not me.
        > >>>>>>>>
        > >>>>>>>> Thanks, I'll put it in the todo list.
        > >>>>>>>>
        > >>>>>>>> How about the patch that Kazunobu Kuriyama sent on Friday?
        > >>>>>>>
        > >>>>>>> Both patches should be fine. Mine uses a configure check to see if
        > >>>>>>> AvailabilityMacros.h is available while Kazonubu Kuriyama used some
        > >>>>>>> compiler defines to check if the header is needed, so his solution is
        > >>>>>>> a bit more lightweight.
        > >>>>>>
        > >>>>>> Just to be clear: So including one or the other works, but I should not
        > >>>>>> include both?
        > >>>>>>
        > >>>>>
        > >>>>> Though Björn Winckler has not replied to Bram’s email above yet, let me try to clarify.
        > >>>>>
        > >>>>> Felix Bünemann’s patch is for building VIM as a Carbon application, while mine is for that as a plain UNIX application, I mean, the latter lets VIM depend only on universal libc and ncurses (and additionally X11) stuff, not on any API such as Carbon or Quartz peculiar to Mac.
        > >>>>>
        > >>>>> That makes a big difference in keyboard response, but this is another story...
        > >>>>>
        > >>>>> From practical and technical points of view, I think both of the patches won’t conflict each other because his patch is mainly for os_mac.h while mine is only for os_unix.c. No intersection, no conflict, though his solution uses the configure script which affects the whole build procedure, thus making it harder to evaluate possible unfavorable impact on the build.
        > >>>>>
        > >>>>> Each of the patches will do for its own purpose.
        > >>>>>
        > >>>>> Hopefully, this clarifies the issue.
        > >>>>>
        > >>>>> Regards,
        > >>>>> KK
        > >>>>
        > >>>> Are we talking about the same patches? I was referring to the patch you send to the vim_dev list with the subject "[patch] src/os_unix.c (for build on Mac OS X 10.9 Mavericks)“.
        > >>>>
        > >>>> To compare https://gist.github.com/6150257 (my patch) and https://gist.github.com/felixbuenemann/7283250 (KK’s patch).
        > >>>>
        > >>>> I think they achieve exactly the same think and the only difference is
        > >>>> that my patch uses configure to check if AvailabilityMacros.h is
        > >>>> available, while KK’s patch uses some existing preprocessor macros.
        > >>>> This means that only one of the patches should be used.
        > >>>
        > >>> I sent out two patches that combine them, using the configure check for
        > >>> Kazonubu's patch as well. Please check it works this way.
        > >>
        > >> Bram,
        > >>
        > >> Please include my patch as it was; otherwise, it won’t work as expected. In fact, Patch 7.4.056 fails to compile os_unix.c.
        > >>
        > >> Let me clarify my point in another way: Felix Bünemann’s patch doesn’t cover the case where the configuration option -—disable-darwin is chosen in the build on the Mac.
        > >>
        > >> I’d like to remind you of Section 1.2 of src/INSTALLmac.txt, that is, there is another way to build vim differently from that of MacVim or alike.
        > >>
        > >> That’s why I sent my patch to vim_dev, not to mac_vim; the patch fixes a problem which is almost irrelevant to MacVim.
        > >
        > > Hmm, why is that configure check inside
        > > "if test "$enable_darwin" = "yes"; then“?
        >
        > It’s inside that block because it seemed the most appropriate place to put it when I wrote that code and I wasn’t aware of the fact that you can compile vim with disable-darwin on OS X.
        >
        > > Checking for header files should be done by configure. using #ifdefs is
        > > bound to break somewhere somewhen.
        > >
        > > What if we move the configure check outside of that "if"? Or pehaps it
        > > should go at the toplevel?
        >
        > That should work.
        >
        > > Looking at it again, I wonder why this doesn't use the normal way of
        > > AC_CHECK_HEADER:
        > >
        > > AC_CHECK_HEADER(AvailabilityMacros.h, HAVE_AVAILABILITYMACROS_H = 1)
        > >
        > > Also, why protect the #include with the version check,
        > > __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__. What happens if we leave
        > > that out?
        >
        > Well there is the remote case of Mac OS X 10.0 and 10.1 where
        > AvailabilityMacros.h is missing

        Then configure wouldn't find it. So one #ifdef would be sufficient.
        So, these version checks only make sense when not using the configure
        defined symbol but checking for the APPLE macro.

        --
        Sometimes I think the surest sign that intelligent life exists elsewhere
        in the universe is that none of it has tried to contact us. (Calvin)

        /// 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_mac" 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

        ---
        You received this message because you are subscribed to the Google Groups "vim_mac" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_mac+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      Your message has been successfully submitted and would be delivered to recipients shortly.