MacVim + Ruby 1.9.1

Hi, I ve always just used the latest MacVim snapshot with the standard Ruby that comes with the system (Ruby 1.8.7) but a user of a plug-in of mine is

Message 1 of 16
, Mar 28 9:49 AM

0 Attachment

Hi,

I've always just used the latest MacVim snapshot with the standard
Ruby that comes with the system (Ruby 1.8.7) but a user of a plug-in
of mine is reporting problems getting it to work under MacVim with
Ruby 1.9.1 so I've been investigating it trying to find out what's
going wrong.

Has anybody had any success getting MacVim running Ruby 1.9.1 on Mac
OS X Snow Leopard 10.6.2? The only message I've been able to find on
the subject is this one, but it's quite out of date now:

So here, at least the 1.9.1 version appears earlier in the PATH, but
VIM is still evidently running with 1.8.7.

Running "otool -L" on the built version of the GUI app yields:

src/MacVim/build/Release/MacVim.app/Contents/MacOS/MacVim:
@executable_path/../Frameworks/PSMTabBarControl.framework/Versions/A/
PSMTabBarControl (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
(compatibility version 1.0.0, current version 15.0.0)
/System/Library/Frameworks/Security.framework/Versions/A/Security
(compatibility version 1.0.0, current version 37594.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
(compatibility version 2.0.0, current version 152.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 125.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current
version 227.0.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/
CoreServices (compatibility version 1.0.0, current version 44.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/
CoreFoundation (compatibility version 150.0.0, current version
550.13.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/
ApplicationServices (compatibility version 1.0.0, current version
38.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
(compatibility version 300.0.0, current version 751.14.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
(compatibility version 45.0.0, current version 1038.25.0)

Note that it's not linking against the Ruby framework, but the command-
line version is; here is the "otool -L" output for that:

src/MacVim/build/Release/MacVim.app/Contents/MacOS/Vim:
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
(compatibility version 1.0.0, current version 15.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
(compatibility version 2.0.0, current version 152.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 125.0.0)
/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current
version 5.4.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current
version 7.0.0)
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/
libruby.1.dylib (compatibility version 1.8.0, current version 1.8.7)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current
version 227.0.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/
CoreServices (compatibility version 1.0.0, current version 44.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/
CoreFoundation (compatibility version 150.0.0, current version
550.13.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
(compatibility version 300.0.0, current version 751.14.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
(compatibility version 45.0.0, current version 1038.25.0)

As one last experiment, I tried building just Vim alone (downloaded
from vim.org) and repeating the tests.

The first difference I noticed is that the MacVim build starts like
this:

--
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

To unsubscribe from this group, send email to vim_mac+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

björn

... These are things you need to consider: (1) MacVim builds links Ruby using the -framework switch, so it will pick up the Ruby version which comes with Mac

Message 3 of 16
, Mar 28 11:08 AM

0 Attachment

On 28 March 2010 18:49, Wincent Colaiuta wrote:

>
> I've always just used the latest MacVim snapshot with the standard
> Ruby that comes with the system (Ruby 1.8.7) but a user of a plug-in
> of mine is reporting problems getting it to work under MacVim with
> Ruby 1.9.1 so I've been investigating it trying to find out what's
> going wrong.
>
> Has anybody had any success getting MacVim running Ruby 1.9.1 on Mac
> OS X Snow Leopard 10.6.2? The only message I've been able to find on
> the subject is this one, but it's quite out of date now:
>
> http://groups.google.com/group/vim_mac/browse_thread/thread/b6684b2396bc88e4/b6831a2715bb8760
>
> Here's what I've tried doing so far:
>
> - set up Ruby 1.9.1 (tried using both RVM and Multiruby with identical
> results)
>
> Running "ruby --version" on the command line reports "ruby 1.9.1p378
> (2010-01-10 revision 26273) [i386-darwin10.2.0]".
>
> - build MacVim while using Ruby 1.9.1

These are things you need to consider:

(1) MacVim builds links Ruby using the -framework switch, so it will
pick up the Ruby version which comes with Mac OS X -- the Ruby version
does not come bundled as a framework I presume? If not you'll have to
either modify src/configure.in to not use the framework, or (after
running configure) manually modify src/auto/config.mk to use the Ruby
version you want (and get rid of the -framework flags).

(2) A patch to support Ruby 1.9 was just recently merged with mainline
Vim -- it has not been tested on Mac OS X as far as I know. Looking
at src/if_ruby.h you have to make sure RUBY_VERSION gets defined
properly (to >=19).

I'm repeating myself, but it has nothing to do with your PATH setting
-- it is the compilation/linking that is causing your problems.

> Running "otool -L" on the built version of the GUI app yields:
>
> src/MacVim/build/Release/MacVim.app/Contents/MacOS/MacVim:
> @executable_path/../Frameworks/PSMTabBarControl.framework/Versions/A/
> PSMTabBarControl (compatibility version 1.0.0, current version 1.0.0)
> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
> (compatibility version 1.0.0, current version 15.0.0)
> /System/Library/Frameworks/Security.framework/Versions/A/Security
> (compatibility version 1.0.0, current version 37594.0.0)
> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
> (compatibility version 2.0.0, current version 152.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 125.0.0)
> /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current
> version 227.0.0)
> /System/Library/Frameworks/CoreServices.framework/Versions/A/
> CoreServices (compatibility version 1.0.0, current version 44.0.0)
> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/
> CoreFoundation (compatibility version 150.0.0, current version
> 550.13.0)
> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/
> ApplicationServices (compatibility version 1.0.0, current version
> 38.0.0)
> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
> (compatibility version 300.0.0, current version 751.14.0)
> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
> (compatibility version 45.0.0, current version 1038.25.0)
>
> Note that it's not linking against the Ruby framework, but the command-
> line version is; here is the "otool -L" output for that:
>
> src/MacVim/build/Release/MacVim.app/Contents/MacOS/Vim:
> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
> (compatibility version 1.0.0, current version 15.0.0)
> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
> (compatibility version 2.0.0, current version 152.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 125.0.0)
> /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current
> version 5.4.0)
> /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current
> version 7.0.0)
> /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/
> libruby.1.dylib (compatibility version 1.8.0, current version 1.8.7)
> /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current
> version 227.0.0)
> /System/Library/Frameworks/CoreServices.framework/Versions/A/
> CoreServices (compatibility version 1.0.0, current version 44.0.0)
> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/
> CoreFoundation (compatibility version 150.0.0, current version
> 550.13.0)
> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
> (compatibility version 300.0.0, current version 751.14.0)
> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
> (compatibility version 45.0.0, current version 1038.25.0)

The MacVim binary does not use Ruby in any way, only the Vim binary
does which explains the otool output. (And here you see also see that
it has linked against your Ruby framework inside
/System/Library/Frameworks)

Ok, if I try answering the rest of your post I'll just keep repeating
myself, but to summarize:

- You need a very recent version of Vim to build with Ruby 1.9 (SVN
should do) but I think it is untested
- If you want to build MacVim with Ruby 1.9 you will have to hack
configure.in (or auto/config.mk)

If you figure it out, please send me a patch (for configure.in).

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

To unsubscribe from this group, send email to vim_mac+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Wayne E. Seguin

Hi Wincent, I use vim & MacVim and wrote RVM so if I can help you test or figure anything out please let me know. I check in here once a week or you can find

Message 4 of 16
, Mar 28 6:27 PM

0 Attachment

Hi Wincent,

I use vim & MacVim and wrote RVM so if I can help you test or figure
anything out please let me know.
I check in here once a week or you can find me in #rvm on
irc.freenode.net during daytime EST hours.

Good Luck!

~Wayne

--
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

To unsubscribe from this group, send email to vim_mac+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Wincent Colaiuta

Thanks for the help. As a first step I hacked the src/auto/config.mk file by hand to see if I could get make to work without errors, setting the Ruby values

Message 5 of 16
, Mar 28 11:21 PM

0 Attachment

Thanks for the help.

As a first step I hacked the src/auto/config.mk file by hand to see if
I could get "make" to work without errors, setting the Ruby values
like this:

On Mon, Mar 29, 2010 at 2:21 AM, Wincent Colaiuta <win@...> wrote:
> Thanks for the help.
>
> As a first step I hacked the src/auto/config.mk file by hand to see if
> I could get "make" to work without errors, setting the Ruby values
> like this:
>
> RUBY = /Users/wincent/.rvm/rubies/ruby-1.9.1-p378/bin/ruby

--
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

To unsubscribe from this group, send email to vim_mac+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Koudelka

Hey guys, I ve successfully compiled MacVim with 1.9.1 under rvm. Here are the config.mk values that worked for me: RUBY =

I've hacked up the configure.in file, too. This is the first time I've
touched an autoconf file, so I can't promise that it has decent style.
But it seems to work, and I don't think it sacrifices backwards
compatibility.

The main problem is that vi_cv_path_ruby was never set, so the entire
conditional for custom rubies was never evaluated.

Should this patch be made against mainline Vim instead of MacVim (i.e.
is there any other platform that might benefit from it)? If so, could
you please create a new patch and send it on to vim_dev? Otherwise
I'll merge it with the MacVim repo.

I took a quick look at the patch but it is not entirely clear to me
what it does? Is it only vi_cv_path_ruby that is set earlier or is
something else going on?

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

Michael Shapiro

... I pulled the vim 7.2 source from http://www.vim.org/sources.php and poked around for ruby config arguments. The provide your own ruby option is missing.

Message 10 of 16
, May 12, 2010

0 Attachment

On May 12, 2010, at 1:39 PM, björn wrote:

> Should this patch be made against mainline Vim instead of MacVim (i.e.
> is there any other platform that might benefit from it)? If so, could
> you please create a new patch and send it on to vim_dev? Otherwise
> I'll merge it with the MacVim repo.

I pulled the vim 7.2 source from http://www.vim.org/sources.php and poked around for ruby config arguments. The 'provide your own ruby' option is missing.

From the OS X-specific nature of the --with-ruby-command option in configure.in, it looks like it wasn't written with other platforms in mind. If it were to be submitted to vim_dev, it should probably be generalized for linux and windows.

>
> I took a quick look at the patch but it is not entirely clear to me
> what it does? Is it only vi_cv_path_ruby that is set earlier or is
> something else going on?

Sorry about the messy patch, I was correcting the indenting at the same time.

The problems were:
1. The original --with-ruby-command assumed that the provided ruby was in the users PATH, and not an absolute path to a ruby binary. (AC_PATH_PROG by default looks in the user's PATH). I've corrected this by providing the path to the binary to AC_PATH_PROG.

2. If a custom ruby is provided, we don't want to use -framework Ruby. There's a conditional to check for that now.

3. The bit of ruby used as a fallback to provide library directories assumed that "." would be one of them. I've corrected that.

The embedded conditional does some checks for ruby on previous versions of OS X, I don't know enough about the state of old versions, so I just left it as the default behavior if an absolute-pathed ruby isn't provided.

Hope that clear things up a bit. :)

--Mike

>
> 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 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

björn

... Mike, could you do me a favor and update this patch against the latest source code version [1] and repost it. Also, please use git-format-patch so that

Message 11 of 16
, Jul 26, 2010

0 Attachment

On 12 May 2010 21:15, Michael Shapiro wrote:

> On May 12, 2010, at 1:39 PM, björn wrote:
>
>> Should this patch be made against mainline Vim instead of MacVim (i.e.
>> is there any other platform that might benefit from it)? If so, could
>> you please create a new patch and send it on to vim_dev? Otherwise
>> I'll merge it with the MacVim repo.
>
> I pulled the vim 7.2 source from http://www.vim.org/sources.php and poked around for ruby config arguments. The 'provide your own ruby' option is missing.
>
> vim72 $ ./configure --help | grep ruby
> --enable-rubyinterp Include Ruby interpreter.
>
> MacVim $ ./configure --help | grep ruby
> --enable-rubyinterp Include Ruby interpreter.
> --with-ruby-command=RUBY name of the Ruby command (default: ruby)
>
> From the OS X-specific nature of the --with-ruby-command option in configure.in, it looks like it wasn't written with other platforms in mind. If it were to be submitted to vim_dev, it should probably be generalized for linux and windows.
>
>>
>> I took a quick look at the patch but it is not entirely clear to me
>> what it does? Is it only vi_cv_path_ruby that is set earlier or is
>> something else going on?
>
> Sorry about the messy patch, I was correcting the indenting at the same time.
>
> Here's a far better patch. http://gist.github.com/398996
>
> The problems were:
> 1. The original --with-ruby-command assumed that the provided ruby was in the users PATH, and not an absolute path to a ruby binary. (AC_PATH_PROG by default looks in the user's PATH). I've corrected this by providing the path to the binary to AC_PATH_PROG.
>
> 2. If a custom ruby is provided, we don't want to use -framework Ruby. There's a conditional to check for that now.
>
> 3. The bit of ruby used as a fallback to provide library directories assumed that "." would be one of them. I've corrected that.
>
> The embedded conditional does some checks for ruby on previous versions of OS X, I don't know enough about the state of old versions, so I just left it as the default behavior if an absolute-pathed ruby isn't provided.
>
> Hope that clear things up a bit. :)

Mike, could you do me a favor and update this patch against the latest
source code version [1] and repost it. Also, please use
git-format-patch so that you get listed as the author of the patch.
As soon as you send me an updated patch I'll take a look at it and
merge asap.

--
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

Michael Shapiro

... You got it, dude. Tested on 10.6.4 with ruby 1.9.1-p378 built by RVM. I forked the repo, if you d prefer just a pull request. (

Message 12 of 16
, Jul 26, 2010

0 Attachment

On Jul 26, 2010, at 2:31 PM, björn wrote:

> On 12 May 2010 21:15, Michael Shapiro wrote:
>> On May 12, 2010, at 1:39 PM, björn wrote:
>>
>>> Should this patch be made against mainline Vim instead of MacVim (i.e.
>>> is there any other platform that might benefit from it)? If so, could
>>> you please create a new patch and send it on to vim_dev? Otherwise
>>> I'll merge it with the MacVim repo.
>>
>> I pulled the vim 7.2 source from http://www.vim.org/sources.php and poked around for ruby config arguments. The 'provide your own ruby' option is missing.
>>
>> vim72 $ ./configure --help | grep ruby
>> --enable-rubyinterp Include Ruby interpreter.
>>
>> MacVim $ ./configure --help | grep ruby
>> --enable-rubyinterp Include Ruby interpreter.
>> --with-ruby-command=RUBY name of the Ruby command (default: ruby)
>>
>> From the OS X-specific nature of the --with-ruby-command option in configure.in, it looks like it wasn't written with other platforms in mind. If it were to be submitted to vim_dev, it should probably be generalized for linux and windows.
>>
>>>
>>> I took a quick look at the patch but it is not entirely clear to me
>>> what it does? Is it only vi_cv_path_ruby that is set earlier or is
>>> something else going on?
>>
>> Sorry about the messy patch, I was correcting the indenting at the same time.
>>
>> Here's a far better patch. http://gist.github.com/398996
>>
>> The problems were:
>> 1. The original --with-ruby-command assumed that the provided ruby was in the users PATH, and not an absolute path to a ruby binary. (AC_PATH_PROG by default looks in the user's PATH). I've corrected this by providing the path to the binary to AC_PATH_PROG.
>>
>> 2. If a custom ruby is provided, we don't want to use -framework Ruby. There's a conditional to check for that now.
>>
>> 3. The bit of ruby used as a fallback to provide library directories assumed that "." would be one of them. I've corrected that.
>>
>> The embedded conditional does some checks for ruby on previous versions of OS X, I don't know enough about the state of old versions, so I just left it as the default behavior if an absolute-pathed ruby isn't provided.
>>
>> Hope that clear things up a bit. :)
>
> Mike, could you do me a favor and update this patch against the latest
> source code version [1] and repost it. Also, please use
> git-format-patch so that you get listed as the author of the patch.
> As soon as you send me an updated patch I'll take a look at it and
> merge asap.
>
> Sorry for taking so long to respond to this patch!
>
> Thanks,
> Björn
>
>
> [1] http://github.com/b4winckler/macvim

--
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

björn

... Thanks, but there is a problem: checking --enable-rubyinterp argument... yes checking --with-ruby-command argument... defaulting to ruby ./configure: line

Message 13 of 16
, Jul 26, 2010

0 Attachment

On 26 July 2010 21:14, Michael Shapiro wrote:

> On Jul 26, 2010, at 2:31 PM, björn wrote:
>
>> On 12 May 2010 21:15, Michael Shapiro wrote:
>>> On May 12, 2010, at 1:39 PM, björn wrote:
>>>
>>>> Should this patch be made against mainline Vim instead of MacVim (i.e.
>>>> is there any other platform that might benefit from it)? If so, could
>>>> you please create a new patch and send it on to vim_dev? Otherwise
>>>> I'll merge it with the MacVim repo.
>>>
>>> I pulled the vim 7.2 source from http://www.vim.org/sources.php and poked around for ruby config arguments. The 'provide your own ruby' option is missing.
>>>
>>> vim72 $ ./configure --help | grep ruby
>>> --enable-rubyinterp Include Ruby interpreter.
>>>
>>> MacVim $ ./configure --help | grep ruby
>>> --enable-rubyinterp Include Ruby interpreter.
>>> --with-ruby-command=RUBY name of the Ruby command (default: ruby)
>>>
>>> From the OS X-specific nature of the --with-ruby-command option in configure.in, it looks like it wasn't written with other platforms in mind. If it were to be submitted to vim_dev, it should probably be generalized for linux and windows.
>>>
>>>>
>>>> I took a quick look at the patch but it is not entirely clear to me
>>>> what it does? Is it only vi_cv_path_ruby that is set earlier or is
>>>> something else going on?
>>>
>>> Sorry about the messy patch, I was correcting the indenting at the same time.
>>>
>>> Here's a far better patch. http://gist.github.com/398996
>>>
>>> The problems were:
>>> 1. The original --with-ruby-command assumed that the provided ruby was in the users PATH, and not an absolute path to a ruby binary. (AC_PATH_PROG by default looks in the user's PATH). I've corrected this by providing the path to the binary to AC_PATH_PROG.
>>>
>>> 2. If a custom ruby is provided, we don't want to use -framework Ruby. There's a conditional to check for that now.
>>>
>>> 3. The bit of ruby used as a fallback to provide library directories assumed that "." would be one of them. I've corrected that.
>>>
>>> The embedded conditional does some checks for ruby on previous versions of OS X, I don't know enough about the state of old versions, so I just left it as the default behavior if an absolute-pathed ruby isn't provided.
>>>
>>> Hope that clear things up a bit. :)
>>
>> Mike, could you do me a favor and update this patch against the latest
>> source code version [1] and repost it. Also, please use
>> git-format-patch so that you get listed as the author of the patch.
>> As soon as you send me an updated patch I'll take a look at it and
>> merge asap.
>>
>> Sorry for taking so long to respond to this patch!
>>
>> Thanks,
>> Björn
>>
>>
>> [1] http://github.com/b4winckler/macvim
>
> You got it, dude.
>
> Tested on 10.6.4 with ruby 1.9.1-p378 built by RVM.

Can you fix this and resend the patch? Also, be careful with
indentation, make sure you have "set noet" (some lines were not
indented correctly).

Thanks,
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

Michael Shapiro

... Hm, Sorry about that. I ve fixed the indenting and removed the need for that conditional completely. --Mike -- You received this message from the vim_mac

Message 14 of 16
, Jul 26, 2010

0 Attachment

On Jul 26, 2010, at 5:31 PM, björn wrote:

> On 26 July 2010 21:14, Michael Shapiro wrote:
>> On Jul 26, 2010, at 2:31 PM, björn wrote:
>>
>>> On 12 May 2010 21:15, Michael Shapiro wrote:
>>>> On May 12, 2010, at 1:39 PM, björn wrote:
>>>>
>>>>> Should this patch be made against mainline Vim instead of MacVim (i.e.
>>>>> is there any other platform that might benefit from it)? If so, could
>>>>> you please create a new patch and send it on to vim_dev? Otherwise
>>>>> I'll merge it with the MacVim repo.
>>>>
>>>> I pulled the vim 7.2 source from http://www.vim.org/sources.php and poked around for ruby config arguments. The 'provide your own ruby' option is missing.
>>>>
>>>> vim72 $ ./configure --help | grep ruby
>>>> --enable-rubyinterp Include Ruby interpreter.
>>>>
>>>> MacVim $ ./configure --help | grep ruby
>>>> --enable-rubyinterp Include Ruby interpreter.
>>>> --with-ruby-command=RUBY name of the Ruby command (default: ruby)
>>>>
>>>> From the OS X-specific nature of the --with-ruby-command option in configure.in, it looks like it wasn't written with other platforms in mind. If it were to be submitted to vim_dev, it should probably be generalized for linux and windows.
>>>>
>>>>>
>>>>> I took a quick look at the patch but it is not entirely clear to me
>>>>> what it does? Is it only vi_cv_path_ruby that is set earlier or is
>>>>> something else going on?
>>>>
>>>> Sorry about the messy patch, I was correcting the indenting at the same time.
>>>>
>>>> Here's a far better patch. http://gist.github.com/398996
>>>>
>>>> The problems were:
>>>> 1. The original --with-ruby-command assumed that the provided ruby was in the users PATH, and not an absolute path to a ruby binary. (AC_PATH_PROG by default looks in the user's PATH). I've corrected this by providing the path to the binary to AC_PATH_PROG.
>>>>
>>>> 2. If a custom ruby is provided, we don't want to use -framework Ruby. There's a conditional to check for that now.
>>>>
>>>> 3. The bit of ruby used as a fallback to provide library directories assumed that "." would be one of them. I've corrected that.
>>>>
>>>> The embedded conditional does some checks for ruby on previous versions of OS X, I don't know enough about the state of old versions, so I just left it as the default behavior if an absolute-pathed ruby isn't provided.
>>>>
>>>> Hope that clear things up a bit. :)
>>>
>>> Mike, could you do me a favor and update this patch against the latest
>>> source code version [1] and repost it. Also, please use
>>> git-format-patch so that you get listed as the author of the patch.
>>> As soon as you send me an updated patch I'll take a look at it and
>>> merge asap.
>>>
>>> Sorry for taking so long to respond to this patch!
>>>
>>> Thanks,
>>> Björn
>>>
>>>
>>> [1] http://github.com/b4winckler/macvim
>>
>> You got it, dude.
>>
>> Tested on 10.6.4 with ruby 1.9.1-p378 built by RVM.
>
> Thanks, but there is a problem:
>
> checking --enable-rubyinterp argument... yes
> checking --with-ruby-command argument... defaulting to ruby
> ./configure: line 5780: test: !=: unary operator expected
> checking for ruby... /usr/bin/ruby
> checking Ruby version... OK
> checking Ruby header files...
> /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin10.0
>
> Line 5780 comes from the following fragment in configure.in:
>
> if test $RUBY_PATH != $RUBY_CMD; then
>
> Can you fix this and resend the patch? Also, be careful with
> indentation, make sure you have "set noet" (some lines were not
> indented correctly).
>
> Thanks,
> Björn

Hm, Sorry about that.

I've fixed the indenting and removed the need for that conditional completely.

--Mike

björn

... Hmmm...have you re-indented lots of lines that your patch didn t change by some chance? All of a sudden the patch touches a lot more lines than the

Hmmm...have you re-indented lots of lines that your patch didn't
change by some chance? All of a sudden the patch touches a lot more
lines than the previous patch. Please take another look at the patch
and send me a minimal patch, otherwise it is difficult for me to see
what has actually changed. (Also, you only need to include
src/configure.in -- I'll generate a new src/configure on my own when I
test the patch.)

Thanks,
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

björn

... Now that the 7.3 release is out of the way I have some time to merge this patch. Michael: can you send me a new (clean) patch based on the latest commit

Message 16 of 16
, Aug 24, 2010

0 Attachment

On 28 July 2010 22:10, björn wrote:

> On 27 July 2010 02:34, Michael Shapiro wrote:
>>
>> On Jul 26, 2010, at 5:31 PM, björn wrote:
>>>
>>> Thanks, but there is a problem:
>>>
>>> checking --enable-rubyinterp argument... yes
>>> checking --with-ruby-command argument... defaulting to ruby
>>> ./configure: line 5780: test: !=: unary operator expected
>>> checking for ruby... /usr/bin/ruby
>>> checking Ruby version... OK
>>> checking Ruby header files...
>>> /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin10.0
>>>
>>> Line 5780 comes from the following fragment in configure.in:
>>>
>>> if test $RUBY_PATH != $RUBY_CMD; then
>>>
>>> Can you fix this and resend the patch? Also, be careful with
>>> indentation, make sure you have "set noet" (some lines were not
>>> indented correctly).
>>
>> Hm, Sorry about that.
>>
>> I've fixed the indenting and removed the need for that conditional completely.
>
> Hmmm...have you re-indented lots of lines that your patch didn't
> change by some chance? All of a sudden the patch touches a lot more
> lines than the previous patch. Please take another look at the patch
> and send me a minimal patch, otherwise it is difficult for me to see
> what has actually changed. (Also, you only need to include
> src/configure.in -- I'll generate a new src/configure on my own when I
> test the patch.)

Now that the 7.3 release is out of the way I have some time to merge
this patch. Michael: can you send me a new (clean) patch based on the
latest commit (note that the repo is now at [1])?