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

Re: why? --disable-darwin configure option

Expand Messages
  • Bram Moolenaar
    ... Thanks, I ll include this. -- An indication you must be a manager: You believe you never have any problems in your life, just issues and improvement
    Message 1 of 28 , Jul 3, 2004
      Raf wrote:

      > p.s. here's a patch that lets configure find the dynamic
      > motif library on macosx.

      Thanks, I'll include this.

      --
      An indication you must be a manager:
      You believe you never have any problems in your life, just
      "issues" and "improvement opportunities".

      /// 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 at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
    • raf
      ... here s another patch that makes --with-x disable darwin support automatically so that vim+athena/motif/gtk can compile (i haven t tested gtk, though). they
      Message 2 of 28 , Jul 3, 2004
        Bram Moolenaar wrote:

        > Raf wrote:
        >
        > > p.s. here's a patch that lets configure find the dynamic
        > > motif library on macosx.
        >
        > Thanks, I'll include this.
        >
        > /// 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 at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///

        here's another patch that makes --with-x disable darwin
        support automatically so that vim+athena/motif/gtk can
        compile (i haven't tested gtk, though). they won't be
        able to use the macosx conversion routines you mentioned
        but i suspect i won't miss them.

        --- src/configure.in.orig Sat Jul 3 22:47:53 2004
        +++ src/configure.in Sun Jul 4 14:51:12 2004
        @@ -20,7 +20,7 @@
        dnl Don't strip if we don't have it
        AC_CHECK_PROG(STRIP, strip, strip, :)

        -dnl Check for extention of executables
        +dnl Check for extension of executables
        AC_EXEEXT

        dnl Set default value for CFLAGS if none is defined or it's empty
        @@ -101,6 +101,17 @@
        AC_MSG_RESULT([yes, Darwin support excluded])
        fi

        + dnl If --with-x was supplied, disable darwin or it won't compile
        + if test "$enable_darwin" = "yes"; then
        + AC_MSG_CHECKING(--with-x argument)
        + if test "$with_x" = "yes"; then
        + AC_MSG_RESULT([yes, Darwin support disabled])
        + enable_darwin=no
        + else
        + AC_MSG_RESULT(no)
        + fi
        + fi
        +
        if test "$enable_darwin" = "yes"; then
        MACOSX=yes
        OS_EXTRA_SCR="os_macosx.c";
      • Bram Moolenaar
        ... I don t quite see the logic behind this solution. If compiling with Athena/Motif/GTK doesn t work, it should not require another configure argument to
        Message 3 of 28 , Jul 4, 2004
          Raf wrote:

          > here's another patch that makes --with-x disable darwin
          > support automatically so that vim+athena/motif/gtk can
          > compile (i haven't tested gtk, though). they won't be
          > able to use the macosx conversion routines you mentioned
          > but i suspect i won't miss them.

          I don't quite see the logic behind this solution. If compiling with
          Athena/Motif/GTK doesn't work, it should not require another configure
          argument to make it work.

          If we can't make the combination of the Darwin stuff with those GUIs
          work, then the Darwin stuff must be disabled automatically.

          --
          ARTHUR: What does it say?
          BROTHER MAYNARD: It reads ... "Here may be found the last words of Joseph of
          Aramathea." "He who is valorous and pure of heart may find
          the Holy Grail in the aaaaarrrrrrggghhh..."
          ARTHUR: What?
          BROTHER MAYNARD: "The Aaaaarrrrrrggghhh..."
          "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

          /// 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 at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
        • raf
          ... but that s exactly what this patch does. it disables darwin support automatically when --with-x has been supplied on the command line so that
          Message 4 of 28 , Jul 4, 2004
            Bram Moolenaar wrote:

            > Raf wrote:
            >
            > > here's another patch that makes --with-x disable darwin
            > > support automatically so that vim+athena/motif/gtk can
            > > compile (i haven't tested gtk, though). they won't be
            > > able to use the macosx conversion routines you mentioned
            > > but i suspect i won't miss them.
            >
            > I don't quite see the logic behind this solution. If compiling with
            > Athena/Motif/GTK doesn't work, it should not require another configure
            > argument to make it work.
            >
            > If we can't make the combination of the Darwin stuff with those GUIs
            > work, then the Darwin stuff must be disabled automatically.

            but that's exactly what this patch does. it disables darwin
            support automatically when --with-x has been supplied on the
            command line so that --disable-darwin isn't required.

            presently, compiling x guis doesn't work unless --disable-darwin
            is supplied. with this patch, when you try to configure an x gui,
            it automatically disables darwin support. the whole point of this
            patch is to remove the need for the extra --disable-darwin argument.

            i don't understand what you mean by "another argument".
            do you mean that --with-x isn't normally needed when
            --enable-gui=athena/motif/gtk is used? i always assumed
            that --with-x was needed for these anyway so it would
            be a good choice. if not, i can come up with a patch
            that checks for x specific enable-gui arguments instead.
            should i do that?

            > --
            > /// 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 at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
          • Bram Moolenaar
            ... Normally you would only use --enable-gui=motif. --with-x is not needed then. Still, before messing with configure, are we sure the problem can t be fixed?
            Message 5 of 28 , Jul 5, 2004
              Raf wrote:

              > > > here's another patch that makes --with-x disable darwin
              > > > support automatically so that vim+athena/motif/gtk can
              > > > compile (i haven't tested gtk, though). they won't be
              > > > able to use the macosx conversion routines you mentioned
              > > > but i suspect i won't miss them.
              > >
              > > I don't quite see the logic behind this solution. If compiling with
              > > Athena/Motif/GTK doesn't work, it should not require another configure
              > > argument to make it work.
              > >
              > > If we can't make the combination of the Darwin stuff with those GUIs
              > > work, then the Darwin stuff must be disabled automatically.
              >
              > but that's exactly what this patch does. it disables darwin
              > support automatically when --with-x has been supplied on the
              > command line so that --disable-darwin isn't required.
              >
              > presently, compiling x guis doesn't work unless --disable-darwin
              > is supplied. with this patch, when you try to configure an x gui,
              > it automatically disables darwin support. the whole point of this
              > patch is to remove the need for the extra --disable-darwin argument.
              >
              > i don't understand what you mean by "another argument".
              > do you mean that --with-x isn't normally needed when
              > --enable-gui=athena/motif/gtk is used? i always assumed
              > that --with-x was needed for these anyway so it would
              > be a good choice. if not, i can come up with a patch
              > that checks for x specific enable-gui arguments instead.
              > should i do that?

              Normally you would only use --enable-gui=motif. --with-x is not needed
              then.

              Still, before messing with configure, are we sure the problem can't be
              fixed? The only thing you showed was a clash in the header files for
              "Cursor". Perhaps including the Carbon headers only where they are
              used, and making sure this code doesn't use the X11 headers we can make
              this work. If this is not possible (e.g., because there are also
              conflicts in the libraries), then disabling Darwin in configure would be
              the only solution.

              --
              To the optimist, the glass is half full.
              To the pessimist, the glass is half empty.
              To the engineer, the glass is twice as big as it needs to be.

              /// 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 at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
            • raf
              ... it turns out that even --with-x --disable-gui fails to ... +++ src/configure.in Thu Jul 8 20:00:12 2004 @@ -101,6 +101,23 @@ AC_MSG_RESULT([yes, Darwin
              Message 6 of 28 , Jul 8, 2004
                Bram Moolenaar wrote:

                > Raf wrote:
                >
                > > > > here's another patch that makes --with-x disable darwin
                > > > > support automatically so that vim+athena/motif/gtk can
                > > > > compile (i haven't tested gtk, though). they won't be
                > > > > able to use the macosx conversion routines you mentioned
                > > > > but i suspect i won't miss them.
                > > >
                > > > I don't quite see the logic behind this solution. If compiling
                > > > with Athena/Motif/GTK doesn't work, it should not require another
                > > > configure argument to make it work.
                > > >
                > > > If we can't make the combination of the Darwin stuff with those
                > > > GUIs work, then the Darwin stuff must be disabled automatically.
                > >
                > > but that's exactly what this patch does. it disables darwin
                > > support automatically when --with-x has been supplied on the
                > > command line so that --disable-darwin isn't required.
                > >
                > > presently, compiling x guis doesn't work unless --disable-darwin
                > > is supplied. with this patch, when you try to configure an x gui,
                > > it automatically disables darwin support. the whole point of this
                > > patch is to remove the need for the extra --disable-darwin argument.
                > >
                > > i don't understand what you mean by "another argument".
                > > do you mean that --with-x isn't normally needed when
                > > --enable-gui=athena/motif/gtk is used? i always assumed
                > > that --with-x was needed for these anyway so it would
                > > be a good choice. if not, i can come up with a patch
                > > that checks for x specific enable-gui arguments instead.
                > > should i do that?
                >
                > Normally you would only use --enable-gui=motif. --with-x is not needed
                > then.

                it turns out that even --with-x --disable-gui fails to
                compile. so the following patch is more accurate:

                --- src/configure.in.orig Sat Jul 3 22:47:53 2004
                +++ src/configure.in Thu Jul 8 20:00:12 2004
                @@ -101,6 +101,23 @@
                AC_MSG_RESULT([yes, Darwin support excluded])
                fi

                + dnl If X11 is requested, disable darwin (conversion routines without Carbon?)
                + if test "$enable_darwin" = "yes"; then
                + AC_MSG_CHECKING(if X11 is requested)
                + if test "$with_x" = "yes"; then
                + AC_MSG_RESULT([yes, Darwin support disabled])
                + enable_darwin=no
                + else
                + case "$enable_gui" in
                + athena|motif|gtk*|gnome*)
                + AC_MSG_RESULT([yes, Darwin support disabled])
                + enable_darwin=no;;
                + *)
                + AC_MSG_RESULT(no);;
                + esac
                + fi
                + fi
                +
                if test "$enable_darwin" = "yes"; then
                MACOSX=yes
                OS_EXTRA_SCR="os_macosx.c";

                > Still, before messing with configure, are we sure the problem can't be
                > fixed? The only thing you showed was a clash in the header files for
                > "Cursor". Perhaps including the Carbon headers only where they are
                > used, and making sure this code doesn't use the X11 headers we can make
                > this work. If this is not possible (e.g., because there are also
                > conflicts in the libraries), then disabling Darwin in configure would be
                > the only solution.

                i've had a quick look. configure turns on the carbon
                framework even when the carbon gui isn't used if multibyte
                or features >= big. this seems to imply that the conversion
                routines require carbon.

                i tried excluding the #includes at the top of os_mac.h unless
                FEAT_GUI_MAC and it compiled with warnings (but tests 12, 25
                and 32 failed) but it didn't compile with multibyte and
                features = big. if i knew which headers were needed by
                carbon and which were needed by the conversion routines,
                i could try to separate them but at the moment i don't
                know anything about either.

                p.s. "make install" of a carbon-enabled vim doesn't actually
                install the Vim.app directory anywhere. it only creates it in
                the src directory. the following patch installs the Vim.app
                directory into the /Applications directory.

                --- src/Makefile.orig Thu Jul 8 20:40:14 2004
                +++ src/Makefile Thu Jul 8 20:47:23 2004
                @@ -2340,6 +2340,7 @@
                REZ = /Developer/Tools/Rez
                APPDIR = $(VIMNAME).app
                RESDIR = $(APPDIR)/Contents/Resources
                +INSDIR = /Applications
                # FIXME: i'm sure someone else can do something clever with grep
                # sed and version.h here
                VERSION = 6.3
                @@ -2361,6 +2362,7 @@

                install_macosx: bundle-dir bundle-executable bundle-info bundle-resource \
                bundle-language
                + $(INSTALL_DATA_R) $(APPDIR) $(INSDIR)

                bundle-dir: $(APPDIR)/Contents $(VIMTARGET)
                -@srcdir=`pwd`; cd $(HELPSOURCE); $(MAKE) VIMEXE=$$srcdir/$(VIMTARGET) vimtags

                > /// 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 at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
              • Benji Fisher
                ... It is odd that make install builds Vim.app but does not put it anywhere, but I have gotten used to it. With this patch, I would have to use something
                Message 7 of 28 , Jul 8, 2004
                  On Thu, Jul 08, 2004 at 11:01:01PM +1000, raf wrote:
                  >
                  > p.s. "make install" of a carbon-enabled vim doesn't actually
                  > install the Vim.app directory anywhere. it only creates it in
                  > the src directory. the following patch installs the Vim.app
                  > directory into the /Applications directory.
                  >
                  > --- src/Makefile.orig Thu Jul 8 20:40:14 2004
                  > +++ src/Makefile Thu Jul 8 20:47:23 2004
                  > @@ -2340,6 +2340,7 @@
                  > REZ = /Developer/Tools/Rez
                  > APPDIR = $(VIMNAME).app
                  > RESDIR = $(APPDIR)/Contents/Resources
                  > +INSDIR = /Applications
                  > # FIXME: i'm sure someone else can do something clever with grep
                  > # sed and version.h here
                  > VERSION = 6.3
                  > @@ -2361,6 +2362,7 @@
                  >
                  > install_macosx: bundle-dir bundle-executable bundle-info bundle-resource \
                  > bundle-language
                  > + $(INSTALL_DATA_R) $(APPDIR) $(INSDIR)
                  >
                  > bundle-dir: $(APPDIR)/Contents $(VIMTARGET)
                  > -@srcdir=`pwd`; cd $(HELPSOURCE); $(MAKE) VIMEXE=$$srcdir/$(VIMTARGET) vimtags

                  It is odd that "make install" builds Vim.app but does not put it
                  anywhere, but I have gotten used to it. With this patch, I would have
                  to use something like

                  $ make install INSDIR=/Users/benji/Applications

                  (if I have the syntax right) if I do not have write access to
                  /Applications . It looks as though INSTALL_DATA_R is just an alias for
                  "cp -r" so I am not going to get anything fancy like a GUI dialogue
                  asking me for an administrator password. So I have two suggestions:

                  1. Use INSTALLDIR instead of INSDIR if the user is supposed to invoke
                  "make install" with this make variable.

                  2. Add something to src/Makefile (and perhaps also a configure argument)
                  so that the user can override the default directory.

                  --Benji Fisher
                • raf
                  ... how about just installing into $(prefix)? that would seem to match the boilerplate (i.e. difficult to modify) output of configure --help most closely
                  Message 8 of 28 , Jul 8, 2004
                    Benji Fisher wrote:

                    > On Thu, Jul 08, 2004 at 11:01:01PM +1000, raf wrote:
                    > >
                    > > p.s. "make install" of a carbon-enabled vim doesn't actually
                    > > install the Vim.app directory anywhere. it only creates it in
                    > > the src directory. the following patch installs the Vim.app
                    > > directory into the /Applications directory.
                    > >
                    > > [...]
                    >
                    > It is odd that "make install" builds Vim.app but does not put it
                    > anywhere, but I have gotten used to it. With this patch, I would have
                    > to use something like
                    >
                    > $ make install INSDIR=/Users/benji/Applications
                    >
                    > (if I have the syntax right) if I do not have write access to
                    > /Applications . It looks as though INSTALL_DATA_R is just an alias for
                    > "cp -r" so I am not going to get anything fancy like a GUI dialogue
                    > asking me for an administrator password. So I have two suggestions:
                    >
                    > 1. Use INSTALLDIR instead of INSDIR if the user is supposed to invoke
                    > "make install" with this make variable.
                    >
                    > 2. Add something to src/Makefile (and perhaps also a configure argument)
                    > so that the user can override the default directory.
                    >
                    > --Benji Fisher

                    how about just installing into $(prefix)? that would seem to
                    match the boilerplate (i.e. difficult to modify) output of
                    "configure --help" most closely although it's slightly wierd. if
                    the --prefix argument isn't used, then make install would install
                    Vim.app into /usr/local which would be just as unexpected as not
                    installing it at all. hmm, maybe not. i seem to recall that i
                    looked in /usr/local/bin after doing make install to see where it
                    had been put. perhaps $(BINDIR) would be better. what do you
                    think? i think "configure --prefix=/Applications" is the most
                    obvious way to make it happen but it would be nice if that was
                    the default for the macosx gui. that probably would require a
                    separate, configurable variable but i can't see how to make
                    an explanation for it appear in "configure --help" as part of
                    the installation directories explanation. it looks like it
                    would have to be part of either the optional features or
                    optional packages section which doesn't make sense.

                    --- Makefile.orig Thu Jul 8 20:40:14 2004
                    +++ Makefile Fri Jul 9 08:12:03 2004
                    @@ -2361,6 +2361,7 @@

                    install_macosx: bundle-dir bundle-executable bundle-info bundle-resource \
                    bundle-language
                    + $(INSTALL_DATA_R) $(APPDIR) $(DESTDIR)$(prefix)

                    bundle-dir: $(APPDIR)/Contents $(VIMTARGET)
                    -@srcdir=`pwd`; cd $(HELPSOURCE); $(MAKE) VIMEXE=$$srcdir/$(VIMTARGET) vimtags
                  • Bram Moolenaar
                    Raf wrote: [about Vim not compiling on the Mac when using an X11 GUI] ... OK, that s better. If we don t manage to solve the conflicts in header files this
                    Message 9 of 28 , Jul 9, 2004
                      Raf wrote:

                      [about Vim not compiling on the Mac when using an X11 GUI]

                      > it turns out that even --with-x --disable-gui fails to
                      > compile. so the following patch is more accurate:

                      OK, that's better. If we don't manage to solve the conflicts in header
                      files this can be used.

                      > > Still, before messing with configure, are we sure the problem can't be
                      > > fixed? The only thing you showed was a clash in the header files for
                      > > "Cursor". Perhaps including the Carbon headers only where they are
                      > > used, and making sure this code doesn't use the X11 headers we can make
                      > > this work. If this is not possible (e.g., because there are also
                      > > conflicts in the libraries), then disabling Darwin in configure would be
                      > > the only solution.
                      >
                      > i've had a quick look. configure turns on the carbon
                      > framework even when the carbon gui isn't used if multibyte
                      > or features >= big. this seems to imply that the conversion
                      > routines require carbon.
                      >
                      > i tried excluding the #includes at the top of os_mac.h unless
                      > FEAT_GUI_MAC and it compiled with warnings (but tests 12, 25
                      > and 32 failed) but it didn't compile with multibyte and
                      > features = big. if i knew which headers were needed by
                      > carbon and which were needed by the conversion routines,
                      > i could try to separate them but at the moment i don't
                      > know anything about either.

                      I'll see if I can find something. I don't have Motif though.

                      > p.s. "make install" of a carbon-enabled vim doesn't actually
                      > install the Vim.app directory anywhere. it only creates it in
                      > the src directory. the following patch installs the Vim.app
                      > directory into the /Applications directory.

                      This is a known drawback. I agree that "make install" should actually
                      install Vim somewhere. Another target could be used to create a Vim.app
                      to try out, like what "make install" does now.

                      I think the normal Unix way to specify the target directory should be
                      used. And the files can directly be copied there, no need to first
                      copy everything inside the src dir.

                      It would be nice if we can do this with a prompt for the root password
                      first, but I have no idea how that should be done.

                      --
                      FIRST SOLDIER: So they wouldn't be able to bring a coconut back anyway.
                      SECOND SOLDIER: Wait a minute! Suppose two swallows carried it together?
                      FIRST SOLDIER: No, they'd have to have it on a line.
                      "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

                      /// 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 at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
                    • raf
                      ... this patch makes make Vim.app create Vim.app in the src directory. then make install copies it to the installation directory separately. ... +++ Makefile
                      Message 10 of 28 , Jul 10, 2004
                        Bram Moolenaar wrote:

                        > Raf wrote:

                        > > p.s. "make install" of a carbon-enabled vim doesn't actually
                        > > install the Vim.app directory anywhere. it only creates it in
                        > > the src directory. the following patch installs the Vim.app
                        > > directory into the /Applications directory.
                        >
                        > This is a known drawback. I agree that "make install" should actually
                        > install Vim somewhere. Another target could be used to create a Vim.app
                        > to try out, like what "make install" does now.

                        this patch makes "make Vim.app" create Vim.app in the src directory.
                        then make install copies it to the installation directory separately.

                        --- Makefile.orig Thu Jul 8 20:40:14 2004
                        +++ Makefile Sat Jul 10 21:33:35 2004
                        @@ -1984,6 +1984,7 @@
                        -rm -f *.o objects/* core $(VIMTARGET).core $(VIMTARGET) xxd/*.o
                        -rm -f $(TOOLS) auto/osdef.h auto/pathdef.c auto/if_perl.c
                        -rm -f conftest* *~ auto/link.sed
                        + -rm -rf $(APPDIR)
                        if test -d $(PODIR); then \
                        cd $(PODIR); $(MAKE) prefix=$(DESTDIR)$(prefix) clean; \
                        fi
                        @@ -2335,7 +2336,7 @@
                        ###############################################################################
                        ### MacOS X installation
                        ###
                        -### This creates a runnable Vim.app in the src directory
                        +### This installs a runnable Vim.app in $(prefix)

                        REZ = /Developer/Tools/Rez
                        APPDIR = $(VIMNAME).app
                        @@ -2359,7 +2360,10 @@
                        #ICON_DOCTXT = $(shell if [ -e doc-txt.icns ] ; then echo doc-txt.icns ; else echo ; fi)
                        #ICONS = $(addprefix $(RESDIR)/, $(ICON_APP) $(ICON_DOC) $(ICON_DOCTXT))

                        -install_macosx: bundle-dir bundle-executable bundle-info bundle-resource \
                        +install_macosx: $(APPDIR)
                        + $(INSTALL_DATA_R) $(APPDIR) $(DESTDIR)$(prefix)
                        +
                        +$(APPDIR): bundle-dir bundle-executable bundle-info bundle-resource \
                        bundle-language

                        bundle-dir: $(APPDIR)/Contents $(VIMTARGET)
                        @@ -2398,11 +2402,8 @@
                        bundle-language: bundle-dir

                        $(APPDIR)/Contents:
                        - mkdir $(APPDIR)
                        - mkdir $(APPDIR)/Contents
                        - mkdir $(APPDIR)/Contents/MacOS
                        - mkdir $(RESDIR)
                        - mkdir $(RESDIR)/English.lproj
                        + -$(SHELL) ./mkinstalldirs $(APPDIR)/Contents/MacOS
                        + -$(SHELL) ./mkinstalldirs $(RESDIR)/English.lproj

                        $(RESDIR)/%.icns: %.icns
                        cp $< $@

                        > I think the normal Unix way to specify the target directory should be
                        > used.

                        yes, but i think that means that "make" on its own should
                        create Vim.app when it's configured to build a carbon gui.
                        that makes it possible for "make test" to perform the :gui
                        test (which doesn't happen at the moment). currently, make
                        only creates the Vim executable which doesn't run properly
                        until it's in the Vim.app directory (it displays the window
                        but it doesn't respond to input).

                        > And the files can directly be copied there, no need to first
                        > copy everything inside the src dir.

                        this patch installs Vim.app directly into $(prefix)
                        without building it in src first.

                        --- Makefile.orig Thu Jul 8 20:40:14 2004
                        +++ Makefile Sat Jul 10 20:45:26 2004
                        @@ -2335,10 +2335,10 @@
                        ###############################################################################
                        ### MacOS X installation
                        ###
                        -### This creates a runnable Vim.app in the src directory
                        +### This installs a runnable Vim.app in $(prefix)

                        REZ = /Developer/Tools/Rez
                        -APPDIR = $(VIMNAME).app
                        +APPDIR = $(DESTDIR)$(prefix)/$(VIMNAME).app
                        RESDIR = $(APPDIR)/Contents/Resources
                        # FIXME: i'm sure someone else can do something clever with grep
                        # sed and version.h here
                        @@ -2398,11 +2398,8 @@
                        bundle-language: bundle-dir

                        $(APPDIR)/Contents:
                        - mkdir $(APPDIR)
                        - mkdir $(APPDIR)/Contents
                        - mkdir $(APPDIR)/Contents/MacOS
                        - mkdir $(RESDIR)
                        - mkdir $(RESDIR)/English.lproj
                        + -$(SHELL) ./mkinstalldirs $(APPDIR)/Contents/MacOS
                        + -$(SHELL) ./mkinstalldirs $(RESDIR)/English.lproj

                        $(RESDIR)/%.icns: %.icns
                        cp $< $@

                        > It would be nice if we can do this with a prompt for the root password
                        > first, but I have no idea how that should be done.

                        i don't see why. that doesn't happen on other systems.
                        i don't think make should turn into a gui installer :)
                        that's what gui installers are for! i figure people who
                        know how to use configure and make probably know when to
                        use su (or --prefix). people who don't, should be able to
                        download a binary.

                        anyway, the default file permissions on macosx are very
                        generous. /Applications is writable to group admin so
                        requiring root privileges would be overkill.

                        > /// 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 at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
                      • Bram Moolenaar
                        ... Eh, this conflicts with the second patch. Can t include them both! ... Agreed. make should generate a working Vim. For the console-only version that s
                        Message 11 of 28 , Jul 10, 2004
                          Raf wrote:

                          > > > p.s. "make install" of a carbon-enabled vim doesn't actually
                          > > > install the Vim.app directory anywhere. it only creates it in
                          > > > the src directory. the following patch installs the Vim.app
                          > > > directory into the /Applications directory.
                          > >
                          > > This is a known drawback. I agree that "make install" should actually
                          > > install Vim somewhere. Another target could be used to create a Vim.app
                          > > to try out, like what "make install" does now.
                          >
                          > this patch makes "make Vim.app" create Vim.app in the src directory.
                          > then make install copies it to the installation directory separately.

                          Eh, this conflicts with the second patch. Can't include them both!

                          > > I think the normal Unix way to specify the target directory should be
                          > > used.
                          >
                          > yes, but i think that means that "make" on its own should
                          > create Vim.app when it's configured to build a carbon gui.
                          > that makes it possible for "make test" to perform the :gui
                          > test (which doesn't happen at the moment). currently, make
                          > only creates the Vim executable which doesn't run properly
                          > until it's in the Vim.app directory (it displays the window
                          > but it doesn't respond to input).

                          Agreed. "make" should generate a working Vim. For the console-only
                          version that's just the "vim" program. For the GUI version Vim.app
                          should be created.

                          Then "make install" can install the "vim" console executable, I suppose
                          just like how it's done on Unix. For the GUI version the Vim.app can be
                          copied to its final location.

                          Now we need some tricks to change what "make" builds. $VIMTARGET should
                          be "Vim.app" for the GUI version. Something needs to be put in
                          auto/config.mk for this.

                          --
                          Looking at Perl through Lisp glasses, Perl looks atrocious.

                          /// 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 at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
                        • raf
                          ... this patch causes Vim.app to be built by make . make test tests :gui and it works. make install installs Vim.app into $(prefix). $VIMTARGET isn t
                          Message 12 of 28 , Jul 15, 2004
                            Bram Moolenaar wrote:

                            > Raf wrote:
                            >
                            > > > I think the normal Unix way to specify the target directory should be
                            > > > used.
                            > >
                            > > yes, but i think that means that "make" on its own should
                            > > create Vim.app when it's configured to build a carbon gui.
                            > > that makes it possible for "make test" to perform the :gui
                            > > test (which doesn't happen at the moment). currently, make
                            > > only creates the Vim executable which doesn't run properly
                            > > until it's in the Vim.app directory (it displays the window
                            > > but it doesn't respond to input).
                            >
                            > Agreed. "make" should generate a working Vim. For the console-only
                            > version that's just the "vim" program. For the GUI version Vim.app
                            > should be created.
                            >
                            > Then "make install" can install the "vim" console executable, I suppose
                            > just like how it's done on Unix. For the GUI version the Vim.app can be
                            > copied to its final location.
                            >
                            > Now we need some tricks to change what "make" builds. $VIMTARGET should
                            > be "Vim.app" for the GUI version. Something needs to be put in
                            > auto/config.mk for this.

                            this patch causes Vim.app to be built by "make". "make test"
                            tests :gui and it works. "make install" installs Vim.app into
                            $(prefix). $VIMTARGET isn't changed because it looks like
                            it's expected to be the executable itself (fair enough).

                            diff -durp vim63.orig/src/Makefile vim63/src/Makefile
                            --- vim63.orig/src/Makefile Mon Jun 7 20:03:56 2004
                            +++ vim63/src/Makefile Thu Jul 15 22:45:41 2004
                            @@ -1167,7 +1167,9 @@ CARBONGUI_LIBS2 =
                            CARBONGUI_INSTALL = install_macosx
                            CARBONGUI_TARGETS =
                            CARBONGUI_MAN_TARGETS =
                            -CARBONGUI_TESTTARGET =
                            +CARBONGUI_TESTTARGET = gui
                            +CARBONGUI_BUNDLE = $(VIMNAME).app
                            +CARBONGUI_TESTARG = VIMPROG=../$(CARBONGUI_BUNDLE)/Contents/MacOS/$(VIMTARGET)

                            # All GUI files
                            ALL_GUI_SRC = gui.c gui_gtk.c gui_gtk_f.c gui_motif.c gui_athena.c gui_gtk_x11.c gui_x11.c gui_at_sb.c gui_at_fs.c pty.c
                            @@ -1434,7 +1436,7 @@ PRO_MANUAL = os_amiga.pro os_msdos.pro o
                            os_mswin.pro os_beos.pro os_vms.pro os_riscos.pro $(PERL_PRO)

                            # Default target is making the executable and tools
                            -all: $(VIMTARGET) $(TOOLS) languages
                            +all: $(VIMTARGET) $(TOOLS) languages $(GUI_BUNDLE)

                            tools: $(TOOLS)

                            @@ -1607,7 +1609,7 @@ types.vim: $(TAGS_SRC) $(TAGS_INCL)
                            #
                            test check:
                            $(MAKE) -f Makefile $(VIMTARGET)
                            - cd testdir; $(MAKE) -f Makefile $(GUI_TESTTARGET) VIMPROG=../$(VIMTARGET)
                            + cd testdir; $(MAKE) -f Makefile $(GUI_TESTTARGET) VIMPROG=../$(VIMTARGET) $(GUI_TESTARG)

                            testclean:
                            cd testdir; $(MAKE) -f Makefile clean
                            @@ -1984,6 +1986,7 @@ clean celan: testclean
                            -rm -f *.o objects/* core $(VIMTARGET).core $(VIMTARGET) xxd/*.o
                            -rm -f $(TOOLS) auto/osdef.h auto/pathdef.c auto/if_perl.c
                            -rm -f conftest* *~ auto/link.sed
                            + -rm -rf $(GUI_BUNDLE)
                            if test -d $(PODIR); then \
                            cd $(PODIR); $(MAKE) prefix=$(DESTDIR)$(prefix) clean; \
                            fi
                            @@ -2335,10 +2338,10 @@ Makefile:
                            ###############################################################################
                            ### MacOS X installation
                            ###
                            -### This creates a runnable Vim.app in the src directory
                            +### This installs a runnable Vim.app in $(prefix)

                            REZ = /Developer/Tools/Rez
                            -APPDIR = $(VIMNAME).app
                            +APPDIR = $(GUI_BUNDLE)
                            RESDIR = $(APPDIR)/Contents/Resources
                            # FIXME: i'm sure someone else can do something clever with grep
                            # sed and version.h here
                            @@ -2359,7 +2362,10 @@ ICONS = $(RESDIR)/$(ICON_APP)
                            #ICON_DOCTXT = $(shell if [ -e doc-txt.icns ] ; then echo doc-txt.icns ; else echo ; fi)
                            #ICONS = $(addprefix $(RESDIR)/, $(ICON_APP) $(ICON_DOC) $(ICON_DOCTXT))

                            -install_macosx: bundle-dir bundle-executable bundle-info bundle-resource \
                            +install_macosx: $(APPDIR)
                            + $(INSTALL_DATA_R) $(APPDIR) $(DESTDIR)$(prefix)
                            +
                            +$(APPDIR): bundle-dir bundle-executable bundle-info bundle-resource \
                            bundle-language

                            bundle-dir: $(APPDIR)/Contents $(VIMTARGET)
                            @@ -2398,11 +2404,8 @@ bundle-rsrc: os_mac.rsr.hqx
                            bundle-language: bundle-dir

                            $(APPDIR)/Contents:
                            - mkdir $(APPDIR)
                            - mkdir $(APPDIR)/Contents
                            - mkdir $(APPDIR)/Contents/MacOS
                            - mkdir $(RESDIR)
                            - mkdir $(RESDIR)/English.lproj
                            + -$(SHELL) ./mkinstalldirs $(APPDIR)/Contents/MacOS
                            + -$(SHELL) ./mkinstalldirs $(RESDIR)/English.lproj

                            $(RESDIR)/%.icns: %.icns
                            cp $< $@
                            diff -durp vim63.orig/src/config.mk.in vim63/src/config.mk.in
                            --- vim63.orig/src/config.mk.in Wed Oct 29 23:30:46 2003
                            +++ vim63/src/config.mk.in Thu Jul 15 22:52:28 2004
                            @@ -120,6 +120,8 @@ GUI_INSTALL = $(@GUITYPE@_INSTALL)
                            GUI_TARGETS = $(@GUITYPE@_TARGETS)
                            GUI_MAN_TARGETS = $(@GUITYPE@_MAN_TARGETS)
                            GUI_TESTTARGET = $(@GUITYPE@_TESTTARGET)
                            +GUI_TESTARG = $(@GUITYPE@_TESTARG)
                            +GUI_BUNDLE = $(@GUITYPE@_BUNDLE)
                            NARROW_PROTO = @NARROW_PROTO@
                            GUI_X_LIBS = @GUI_X_LIBS@
                            MOTIF_LIBNAME = @MOTIF_LIBNAME@

                            > --
                            > /// 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 at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
                          • Bram Moolenaar
                            ... I twisted the code so that running configure with --enable-gui=motif builds Vim the right way without other configure arguments. Also for Athena and
                            Message 13 of 28 , Jul 18, 2004
                              Raf wrote:

                              > > > > here's another patch that makes --with-x disable darwin
                              > > > > support automatically so that vim+athena/motif/gtk can
                              > > > > compile (i haven't tested gtk, though). they won't be
                              > > > > able to use the macosx conversion routines you mentioned
                              > > > > but i suspect i won't miss them.

                              I twisted the code so that running configure with "--enable-gui=motif"
                              builds Vim the right way without other configure arguments. Also for
                              Athena and GTK. The conversion routines are still included.

                              I moved the conversion functions to a separate file os_mac_conv.c.
                              In that file NO_X11_INCLUDES is defined, so that the Darwin/Carbon
                              include files can be used and all the X11 stuff is not included.

                              I can only test that it compiles now. Linking fails for me, because I
                              don't have the Xt library. I copied the X11 header files from a Unix
                              system. I could not find these available for download, the X11 server
                              apparently comes without support for development.

                              I'll check it into CVS later. Please do check it out, it is getting
                              quite complicated. It might fail with a few different configure
                              options.

                              --
                              Far back in the mists of ancient time, in the great and glorious days of the
                              former Galactic Empire, life was wild, rich and largely tax free.
                              Mighty starships plied their way between exotic suns, seeking adventure and
                              reward among the furthest reaches of Galactic space. In those days, spirits
                              were brave, the stakes were high, men were real men, women were real women
                              and small furry creatures from Alpha Centauri were real small furry creatures
                              from Alpha Centauri. And all dared to brave unknown terrors, to do mighty
                              deeds, to boldly split infinitives that no man had split before -- and thus
                              was the Empire forged.
                              -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

                              /// 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 at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
                            • raf
                              ... that s odd. it included everything when i downloaded it (presumably) from: http://www.apple.com/macosx/features/x11/download/ (41.7MB) it s certainly big
                              Message 14 of 28 , Jul 19, 2004
                                Bram Moolenaar wrote:

                                > Raf wrote:
                                >
                                > > > > > here's another patch that makes --with-x disable darwin
                                > > > > > support automatically so that vim+athena/motif/gtk can
                                > > > > > compile (i haven't tested gtk, though). they won't be
                                > > > > > able to use the macosx conversion routines you mentioned
                                > > > > > but i suspect i won't miss them.
                                >
                                > I twisted the code so that running configure with "--enable-gui=motif"
                                > builds Vim the right way without other configure arguments. Also for
                                > Athena and GTK. The conversion routines are still included.
                                >
                                > I moved the conversion functions to a separate file os_mac_conv.c.
                                > In that file NO_X11_INCLUDES is defined, so that the Darwin/Carbon
                                > include files can be used and all the X11 stuff is not included.
                                >
                                > I can only test that it compiles now. Linking fails for me, because I
                                > don't have the Xt library. I copied the X11 header files from a Unix
                                > system. I could not find these available for download, the X11 server
                                > apparently comes without support for development.

                                that's odd. it included everything when i downloaded it (presumably) from:
                                http://www.apple.com/macosx/features/x11/download/ (41.7MB)
                                it's certainly big enough to include everything :)

                                > I'll check it into CVS later. Please do check it out, it is getting
                                > quite complicated. It might fail with a few different configure
                                > options.

                                will do.

                                > /// 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 at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
                              • Bram Moolenaar
                                ... I think you must also have obtained the SDK somehow. In the sidebar it says: X11 for Mac OS X SDK The software developer?s kit contains headers and other
                                Message 15 of 28 , Jul 20, 2004
                                  Raf wrote:

                                  > > I can only test that it compiles now. Linking fails for me, because I
                                  > > don't have the Xt library. I copied the X11 header files from a Unix
                                  > > system. I could not find these available for download, the X11 server
                                  > > apparently comes without support for development.
                                  >
                                  > that's odd. it included everything when i downloaded it (presumably) from:
                                  > http://www.apple.com/macosx/features/x11/download/ (41.7MB)
                                  > it's certainly big enough to include everything :)

                                  I think you must also have obtained the SDK somehow. In the sidebar it
                                  says:

                                  X11 for Mac OS X SDK
                                  The software developer?s kit contains headers and other support
                                  files for X11, and is only needed if you want to compile your
                                  own X11 applications on Mac OS X v10.3. It is available on the
                                  Panther Developer CD as an optional package.

                                  I'm still running 10.2, thus have to find old stuff anyway. I keep
                                  finding more reasons to buy 10.3...

                                  --
                                  I am also told that there is a logical proof out there somewhere
                                  that demonstrates that there is no task which duct tape cannot handle.
                                  -- Paul Brannan

                                  /// 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 at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
                                • raf
                                  ... ah, it must have been on the installation dvd (no separate cd for development). ... 10.4 will probably be out soon. grr. i wish they were happy with the
                                  Message 16 of 28 , Jul 20, 2004
                                    Bram Moolenaar wrote:

                                    > Raf wrote:
                                    >
                                    > > > I can only test that it compiles now. Linking fails for me, because I
                                    > > > don't have the Xt library. I copied the X11 header files from a Unix
                                    > > > system. I could not find these available for download, the X11 server
                                    > > > apparently comes without support for development.
                                    > >
                                    > > that's odd. it included everything when i downloaded it (presumably) from:
                                    > > http://www.apple.com/macosx/features/x11/download/ (41.7MB)
                                    > > it's certainly big enough to include everything :)
                                    >
                                    > I think you must also have obtained the SDK somehow. In the sidebar it
                                    > says:
                                    >
                                    > X11 for Mac OS X SDK
                                    > The software developer?s kit contains headers and other support
                                    > files for X11, and is only needed if you want to compile your
                                    > own X11 applications on Mac OS X v10.3. It is available on the
                                    > Panther Developer CD as an optional package.

                                    ah, it must have been on the installation dvd (no separate
                                    cd for development).

                                    > I'm still running 10.2, thus have to find old stuff anyway. I keep
                                    > finding more reasons to buy 10.3...

                                    10.4 will probably be out soon. grr. i wish they were happy with
                                    the hardware revenue and just let us download software updates.

                                    > --
                                    > I am also told that there is a logical proof out there somewhere
                                    > that demonstrates that there is no task which duct tape cannot handle.
                                    > -- Paul Brannan
                                    >
                                    > /// 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 at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
                                  • raf
                                    ... there was a missing from Filelist and then it compiled and linked fine but 3 tests failed (12, 25, 32). a patch and the src/testdir/*.failed files are
                                    Message 17 of 28 , Jul 21, 2004
                                      raf wrote:

                                      > Bram Moolenaar wrote:
                                      >
                                      > > I twisted the code so that running configure with "--enable-gui=motif"
                                      > > builds Vim the right way without other configure arguments. Also for
                                      > > Athena and GTK. The conversion routines are still included.
                                      > >
                                      > > I moved the conversion functions to a separate file os_mac_conv.c.
                                      > > In that file NO_X11_INCLUDES is defined, so that the Darwin/Carbon
                                      > > include files can be used and all the X11 stuff is not included.
                                      > >
                                      > > I can only test that it compiles now. Linking fails for me, because I
                                      > > don't have the Xt library. I copied the X11 header files from a Unix
                                      > > system. I could not find these available for download, the X11 server
                                      > > apparently comes without support for development.

                                      > > I'll check it into CVS later. Please do check it out, it is getting
                                      > > quite complicated. It might fail with a few different configure
                                      > > options.

                                      there was a \ missing from Filelist and then it compiled and
                                      linked fine but 3 tests failed (12, 25, 32). a patch and the
                                      src/testdir/*.failed files are attached.

                                      > > /// 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 at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
                                    • Bram Moolenaar
                                      ... Very strange, this has nothing to do with the GUI code. Test32 is sensitive to other files being present in the directory, try make testclean . I now
                                      Message 18 of 28 , Jul 21, 2004
                                        Raf wrote:

                                        > there was a \ missing from Filelist and then it compiled and
                                        > linked fine but 3 tests failed (12, 25, 32). a patch and the
                                        > src/testdir/*.failed files are attached.

                                        Very strange, this has nothing to do with the GUI code. Test32 is
                                        sensitive to other files being present in the directory, try "make
                                        testclean".

                                        I now managed to build an Athena version (with lots of manual tweaks for
                                        my system files). "make test" fails for me too. I'll try again with a
                                        clean setup.

                                        --
                                        It is hard to understand how a cemetery raised its burial
                                        cost and blamed it on the cost of living.

                                        /// 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 at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
                                      • raf
                                        ... i spoke too soon. that was with motif+max+multibyte. a default configure (carbon) failed to compile because multibyte wasn t enabled. the ugly patch below
                                        Message 19 of 28 , Jul 21, 2004
                                          raf wrote:

                                          > > Bram Moolenaar wrote:
                                          > >
                                          > > I twisted the code so that running configure with "--enable-gui=motif"
                                          > > builds Vim the right way without other configure arguments. Also for
                                          > > Athena and GTK. The conversion routines are still included.
                                          > >
                                          > > I moved the conversion functions to a separate file os_mac_conv.c.
                                          > > In that file NO_X11_INCLUDES is defined, so that the Darwin/Carbon
                                          > > include files can be used and all the X11 stuff is not included.
                                          > >
                                          > > I can only test that it compiles now. Linking fails for me, because I
                                          > > don't have the Xt library. I copied the X11 header files from a Unix
                                          > > system. I could not find these available for download, the X11 server
                                          > > apparently comes without support for development.
                                          >
                                          > > I'll check it into CVS later. Please do check it out, it is getting
                                          > > quite complicated. It might fail with a few different configure
                                          > > options.
                                          >
                                          > there was a \ missing from Filelist and then it compiled and
                                          > linked fine but 3 tests failed (12, 25, 32). a patch and the
                                          > src/testdir/*.failed files are attached.

                                          i spoke too soon. that was with motif+max+multibyte. a default
                                          configure (carbon) failed to compile because multibyte wasn't enabled.
                                          the ugly patch below makes carbon builds work with or without multibyte.

                                          motif+multibyte build ok, tests 12,25,32 fail.
                                          motif-multibyte fails to link:

                                          ld: objects/os_mac_conv.o illegal reference to symbol: _CFRelease defined in indirectly referenced dynamic library /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
                                          ld: warning suggest use of -bind_at_load, as lazy binding may result in errors or different symbols being used
                                          symbol _XauDisposeAuth used from dynamic library /usr/X11R6/lib/libX11.dylib(AuDispose.o) not from earlier dynamic library /usr/X11R6/lib/libXp.6.dylib(AuDispose.o)
                                          symbol _XauReadAuth used from dynamic library /usr/X11R6/lib/libX11.dylib(AuRead.o) not from earlier dynamic library /usr/X11R6/lib/libXp.6.dylib(AuRead.o)

                                          nogui+multibyte build ok, test ok.
                                          nogui-multibyte fails to link:

                                          ld: Undefined symbols:
                                          _CFRelease
                                          _CFStringCreateWithBytes
                                          _CFStringGetBytes
                                          _CFStringGetCString
                                          _CFStringGetLength

                                          it looks like the carbon framework might be necessary
                                          even when multibyte is not enabled.

                                          > > /// 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 at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///

                                          --- src/os_mac_conv.c.orig Thu Jul 22 01:07:45 2004
                                          +++ src/os_mac_conv.c Thu Jul 22 01:02:43 2004
                                          @@ -43,14 +43,18 @@ mac_string_convert(ptr, len, lenp, fail_
                                          {
                                          case 'l': from = kCFStringEncodingISOLatin1; break;
                                          case 'm': from = kCFStringEncodingMacRoman; break;
                                          +#ifdef FEAT_MBYTE
                                          case 'u': from = kCFStringEncodingUTF8; break;
                                          +#endif
                                          default: return NULL;
                                          }
                                          switch (to_enc)
                                          {
                                          case 'l': to = kCFStringEncodingISOLatin1; break;
                                          case 'm': to = kCFStringEncodingMacRoman; break;
                                          +#ifdef FEAT_MBYTE
                                          case 'u': to = kCFStringEncodingUTF8; break;
                                          +#endif
                                          default: return NULL;
                                          }

                                          @@ -69,9 +73,11 @@ mac_string_convert(ptr, len, lenp, fail_
                                          }
                                          if (cfstr == NULL)
                                          return NULL;
                                          +#ifdef FEAT_MBYTE
                                          if (to == kCFStringEncodingUTF8)
                                          buflen = len * 6 + 1;
                                          else
                                          +#endif
                                          buflen = len + 1;
                                          retval = alloc(buflen);
                                          if (retval == NULL)
                                          @@ -92,9 +98,11 @@ mac_string_convert(ptr, len, lenp, fail_
                                          * for each character */
                                          for (d = retval, in = 0, out = 0; in < len && out < buflen - 1;)
                                          {
                                          +#ifdef FEAT_MBYTE
                                          if (from == kCFStringEncodingUTF8)
                                          l = utf_ptr2len_check(ptr + in);
                                          else
                                          +#endif
                                          l = 1;
                                          cfstr = CFStringCreateWithBytes(NULL, ptr + in, l, from, 0);
                                          if (cfstr == NULL)
                                          @@ -162,7 +170,11 @@ macroman2enc(ptr, sizep, real_size)
                                          r.location = 0;
                                          r.length = CFStringGetLength(cfstr);
                                          if (r.length != CFStringGetBytes(cfstr, r,
                                          +#ifdef FEAT_MBYTE
                                          (enc_utf8) ? kCFStringEncodingUTF8 : kCFStringEncodingISOLatin1,
                                          +#else
                                          + kCFStringEncodingISOLatin1,
                                          +#endif
                                          0, /* no lossy conversion */
                                          0, /* not external representation */
                                          ptr + *sizep, real_size - *sizep, &len))
                                          @@ -200,13 +212,21 @@ enc2macroman(from, fromlen, to, tolenp,

                                          *restlenp = 0;
                                          cfstr = CFStringCreateWithBytes(NULL, from, fromlen,
                                          +#ifdef FEAT_MBYTE
                                          (enc_utf8) ? kCFStringEncodingUTF8 : kCFStringEncodingISOLatin1,
                                          +#else
                                          + kCFStringEncodingISOLatin1,
                                          +#endif
                                          0);
                                          while (cfstr == NULL && *restlenp < 3 && fromlen > 1)
                                          {
                                          rest[*restlenp++] = from[--fromlen];
                                          cfstr = CFStringCreateWithBytes(NULL, from, fromlen,
                                          +#ifdef FEAT_MBYTE
                                          (enc_utf8) ? kCFStringEncodingUTF8 : kCFStringEncodingISOLatin1,
                                          +#else
                                          + kCFStringEncodingISOLatin1,
                                          +#endif
                                          0);
                                          }
                                          if (cfstr == NULL)
                                        • Bram Moolenaar
                                          ... Either that, or all the code in os_mac_conv.c needs to be disabled. I think the code won t be used without the multi-byte feature anyway, thus we might as
                                          Message 20 of 28 , Jul 21, 2004
                                            raf wrote:

                                            > i spoke too soon. that was with motif+max+multibyte. a default
                                            > configure (carbon) failed to compile because multibyte wasn't enabled.
                                            > the ugly patch below makes carbon builds work with or without multibyte.

                                            > it looks like the carbon framework might be necessary
                                            > even when multibyte is not enabled.

                                            Either that, or all the code in os_mac_conv.c needs to be disabled. I
                                            think the code won't be used without the multi-byte feature anyway, thus
                                            we might as well disable it.

                                            The problem with test25 apparently has something to do with using ":"
                                            for a path separator. ":cd dir" also doesn't work. I'm still looking
                                            into it, but also a few other things to do.

                                            --
                                            The 50-50-90 rule: Anytime you have a 50-50 chance of getting
                                            something right, there's a 90% probability you'll get it wrong.

                                            /// 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 at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
                                          • Bram Moolenaar
                                            ... I think I found a solution. In os_mac.h COLON_AS_PATHSEP is defined. For some reason TARGET_API_MAC_OSX isn t defined even though we are on OS X. I did
                                            Message 21 of 28 , Jul 21, 2004
                                              I wrote:

                                              > raf wrote:
                                              >
                                              > > i spoke too soon. that was with motif+max+multibyte. a default
                                              > > configure (carbon) failed to compile because multibyte wasn't enabled.
                                              > > the ugly patch below makes carbon builds work with or without multibyte.
                                              >
                                              > > it looks like the carbon framework might be necessary
                                              > > even when multibyte is not enabled.
                                              >
                                              > Either that, or all the code in os_mac_conv.c needs to be disabled. I
                                              > think the code won't be used without the multi-byte feature anyway, thus
                                              > we might as well disable it.
                                              >
                                              > The problem with test25 apparently has something to do with using ":"
                                              > for a path separator. ":cd dir" also doesn't work. I'm still looking
                                              > into it, but also a few other things to do.

                                              I think I found a solution. In os_mac.h COLON_AS_PATHSEP is defined.
                                              For some reason TARGET_API_MAC_OSX isn't defined even though we are on
                                              OS X. I did this:

                                              *** os_mac.h~ Wed Jul 21 19:35:46 2004
                                              --- os_mac.h Wed Jul 21 21:42:47 2004
                                              ***************
                                              *** 119,126 ****
                                              * ~/Library/Vim or ~/Library/Preferences/org.vim.vim/ ? (Dany)
                                              */
                                              /* When compiled under MacOS X (including CARBON version)
                                              ! * we use the Unix File path style */
                                              ! #if defined(TARGET_API_MAC_OSX) && TARGET_API_MAC_OSX
                                              # undef COLON_AS_PATHSEP
                                              # define USE_UNIXFILENAME
                                              #else
                                              --- 119,126 ----
                                              * ~/Library/Vim or ~/Library/Preferences/org.vim.vim/ ? (Dany)
                                              */
                                              /* When compiled under MacOS X (including CARBON version)
                                              ! * we use the Unix File path style. Also when UNIX is defined. */
                                              ! #if defined(UNIX) || (defined(TARGET_API_MAC_OSX) && TARGET_API_MAC_OSX)
                                              # undef COLON_AS_PATHSEP
                                              # define USE_UNIXFILENAME
                                              #else

                                              Now all tests pass.

                                              Would there be any situation where this change causes trouble? I can't
                                              imagine UNIX is defined when colons are used for path separator.

                                              --
                                              George: "I just got a new set of golf clubs for my wife!"
                                              John: "Great trade!"

                                              /// 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 at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
                                            • raf
                                              ... fair enough. at least it doesn t depend on carbon anymore! if the only pre-requisite is multi-byte, i can t imagine any complaints. forcing (or defaulting
                                              Message 22 of 28 , Jul 22, 2004
                                                Bram Moolenaar wrote:

                                                > raf wrote:
                                                >
                                                > > i spoke too soon. that was with motif+max+multibyte. a default
                                                > > configure (carbon) failed to compile because multibyte wasn't enabled.
                                                > > the ugly patch below makes carbon builds work with or without multibyte.
                                                >
                                                > > it looks like the carbon framework might be necessary
                                                > > even when multibyte is not enabled.
                                                >
                                                > Either that, or all the code in os_mac_conv.c needs to be disabled. I
                                                > think the code won't be used without the multi-byte feature anyway, thus
                                                > we might as well disable it.

                                                fair enough. at least it doesn't depend on carbon anymore!
                                                if the only pre-requisite is multi-byte, i can't imagine
                                                any complaints. forcing (or defaulting to) multi-byte on
                                                macosx could also be done but that might be a bit rude.

                                                > --
                                                > /// 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 at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
                                              • raf
                                                ... yay! ... that would be perverse.
                                                Message 23 of 28 , Jul 22, 2004
                                                  Bram Moolenaar wrote:
                                                  > raf wrote:
                                                  > > The problem with test25 apparently has something to do with using ":"
                                                  > > for a path separator. ":cd dir" also doesn't work. I'm still looking
                                                  > > into it, but also a few other things to do.
                                                  >
                                                  > I think I found a solution. In os_mac.h COLON_AS_PATHSEP is defined.
                                                  > For some reason TARGET_API_MAC_OSX isn't defined even though we are on
                                                  > OS X. I did this:
                                                  >
                                                  > [patch]
                                                  >
                                                  > Now all tests pass.

                                                  yay!

                                                  > Would there be any situation where this change causes trouble? I can't
                                                  > imagine UNIX is defined when colons are used for path separator.

                                                  that would be perverse.
                                                Your message has been successfully submitted and would be delivered to recipients shortly.