MacVim + Ruby 1.9.1
Wincent Colaiuta
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
During configure (with "./configure --with-features=huge --enable-
rubyinterp"), it reports:
checking --enable-rubyinterp argument... yes
checking --with-ruby-command argument... defaulting to ruby
checking for ruby... /Users/wincent/.rvm/rubies/ruby-1.9.1-p378/bin/
ruby
checking Ruby version... OK
checking Ruby header files... /Users/wincent/.rvm/rubies/ruby-1.9.1-
p378/include/ruby-1.9.1
So you would expect it to compile using Ruby 1.9.1, but at runtime in
MacVim (the GUI version), this:
:ruby p RUBY_VERSION
Prints:
"1.8.7"
And:
:ruby p ENV['PATH']
Prints:
"/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/Users/
wincent/.rvm/rubies/ruby-1.9.1-p378/bin:/Users/wincent/.rvm/gems/r
uby-1.9.1-p378/bin:/Users/wincent/.rvm/gems/ruby-1.9.1-p378%global/
bin:/Users/wincent/.rvm/bin:/usr/local/sbin:/Users/wincent/bin:/D
eveloper/Tools:/usr/X11R6/bin:/usr/local/mysql/bin:/usr/local/jruby/
bin:/Users/wincent/bin/ec2-api-tools-1.3-46266/bin:/usr/local/bi
n:/Users/wincent/bin:/Developer/Tools:/usr/X11R6/bin:/usr/local/mysql/
bin:/usr/local/jruby/bin:/Users/wincent/bin/ec2-api-tools-1.3-
46266/bin"
As you can see, the standard system Ruby (/usr/bin/ruby) will take
precedence because it appears at the start of the PATH.
Using the just-built Vim from the command line, this:
:ruby p RUBY_VERSION
Prints:
"1.8.7"
And:
:ruby p ENV['PATH']
Prints:
"/Users/wincent/.rvm/rubies/ruby-1.9.1-p378/bin:/Users/wincent/.rvm/
gems/ruby-1.9.1-p378/bin:/Users/wincent/.rvm/gems/ruby-1.9.1-p378%
global/bin:/Users/wincent/.rvm/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/
local/bin:/usr/X11/bin:/usr/local/sbin:/Users/wincent/bin:/Devel
oper/Tools:/usr/X11R6/bin:/usr/local/mysql/bin:/usr/local/jruby/bin:/
Users/wincent/bin/ec2-api-tools-1.3-46266/bin"
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:
CC="gcc -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-
pragmas -pipe -DMACOS_X_UNIX -no-cpp-precomp " srcdir=. sh ./
osdef.sh
gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-
unknown-pragmas -pipe -DMACOS_X_UNIX -no-cpp-precomp -g -O2 -
D_FORTIFY_SOURCE=1 -o objects/buffer.o buffer.c
Whereas upstream Vim like this:
CC="gcc -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_ATHENA -I/usr/X11/
include -I/Users/wincent/.rvm/rubies/ruby-1.9.1-p378/lib/ruby/
1.9.1/i386-darwin10.2.0 " srcdir=. sh ./osdef.sh
gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_ATHENA -g -O2 -I/
usr/X11/include -I/Users/wincent/.rvm/rubies/ruby-1.9.1-p378/lib/
ruby/1.9.1/i386-darwin10.2.0 -o objects/buffer.o buffer.c
Note how upstream Vim explicitly specifies the Ruby header files
include path.
But the upstream Vim doesn't actually seem to compile on Snow Leopard.
Partway through the build it dies with:
if_ruby.c:51:18: error: ruby.h: No such file or directory
If I explicitly specify the include header path:
./configure --with-features=huge --enable-rubyinterp CFLAGS="-I/
Users/wincent/.rvm/rubies/ruby-1.9.1-p378/include/ruby-1.9.1"
Then the build gets a little further before choking:
if_ruby.c: In function ‘error_print’:
if_ruby.c:473: error: ‘struct RString’ has no member named ‘len’
Evidently the upstream VIM 7.2, which is now quite old, only has Ruby
1.8 support.
So I try an SVN checkout of current trunk and unfortunately that fails
in a different way:
gui_mac.c:6895: warning: implicit declaration of function
‘RevealDataBrowserItem’
make[1]: *** [objects/gui_mac.o] Error 1
make: *** [first] Error 2
I try again this time passing "--disable-gui" to "configure" and this
time we fail like so:
gcc -L. -L/usr/local/lib -L/usr/local/lib -o vim objects/
buffer.o objects/charset.o objects/diff.o objects/digraph.o objects/
edit.o objects/eval.o objects/ex_cmds.o objects/ex_cmds2.o objects/
ex_docmd.o objects/ex_eval.o objects/ex_getln.o objects/fileio.o
objects/fold.o objects/getchar.o objects/hardcopy.o objects/hashtab.o
objects/if_cscope.o objects/if_xcmdsrv.o objects/main.o objects/mark.o
objects/memfile.o objects/memline.o objects/menu.o objects/message.o
objects/misc1.o objects/misc2.o objects/move.o objects/mbyte.o objects/
normal.o objects/ops.o objects/option.o objects/os_unix.o objects/
pathdef.o objects/popupmnu.o objects/quickfix.o objects/regexp.o
objects/screen.o objects/search.o objects/spell.o objects/syntax.o
objects/tag.o objects/term.o objects/ui.o objects/undo.o objects/
window.o objects/if_ruby.o objects/os_macosx.o objects/
os_mac_conv.o objects/netbeans.o objects/version.o -lm -
lncurses -liconv -framework Carbon -lruby-static -lpthread -ldl -
lobjc
ld: library not found for -lruby-static
collect2: ld returned 1 exit status
make[1]: *** [vim] Error 1
make: *** [first] Error 2
Switching back to the system installed Ruby 1.8.7 this build process
works fine.
So here I'm kind of at a dead end.
Can anybody shed any light on the subject of Vim + Ruby 1.9.1 on Snow
Leopard?
Cheers,
Wincent
Wincent Colaiuta
https://wincent.com/issues/1524
And this is a post on the vim_dev list on the current status of Ruby
1.9 support which I found after writing my post above:
http://groups.google.com/group/vim_dev/browse_thread/thread/a34ba9d02c57af9a/57ab7457327c81d8
Cheers,
Wincent
björn
>
> 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).
> During configure (with "./configure --with-features=huge --enable-
> rubyinterp"), it reports:
>
> checking --enable-rubyinterp argument... yes
> checking --with-ruby-command argument... defaulting to ruby
> checking for ruby... /Users/wincent/.rvm/rubies/ruby-1.9.1-p378/bin/
> ruby
> checking Ruby version... OK
> checking Ruby header files... /Users/wincent/.rvm/rubies/ruby-1.9.1-
> p378/include/ruby-1.9.1
This only means that it finds your updated Ruby binary first -- the
-framework flag willl cause this to be ignored.
I'm repeating myself, but it has nothing to do with your PATH setting
-- it is the compilation/linking that is causing your problems.
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
Wayne E. Seguin
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
Wincent Colaiuta
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
RUBY_SRC = if_ruby.c
RUBY_OBJ = objects/if_ruby.o
RUBY_PRO = if_ruby.pro
RUBY_CFLAGS = -I/Users/wincent/.rvm/rubies/ruby-1.9.1-p378/include/
ruby-1.9.1 -DRUBY_VERSION="19"
RUBY_LIBS = -L/Users/wincent/.rvm/rubies/ruby-1.9.1-p378/lib -
lruby-static
No idea if my "-l" setting is correct seeing as "make" doesn't get as
far as linking anyway:
gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-
unknown-pragmas -pipe -DMACOS_X_UNIX -no-cpp-precomp -g -O2 -
D_FORTIFY_SOURCE=1 -I/Users/wincent/.rvm/rubies/ruby-1.9.1-p378/
include/ruby-1.9.1 -DRUBY_VERSION="19" -o objects/if_ruby.o if_ruby.c
In file included from /Users/wincent/.rvm/rubies/ruby-1.9.1-p378/
include/ruby-1.9.1/Ruby/ruby.h:1125,
from if_ruby.c:69:
/Users/wincent/.rvm/rubies/ruby-1.9.1-p378/include/ruby-1.9.1/ruby/
missing.h:35: error: redefinition of ‘struct timespec’
In file included from /Users/wincent/.rvm/rubies/ruby-1.9.1-p378/
include/ruby-1.9.1/Ruby/ruby.h:1125,
from if_ruby.c:69:
/Users/wincent/.rvm/rubies/ruby-1.9.1-p378/include/ruby-1.9.1/ruby/
missing.h:151: error: expected declaration specifiers or ‘...’ before
numeric constant
/Users/wincent/.rvm/rubies/ruby-1.9.1-p378/include/ruby-1.9.1/ruby/
missing.h:151: error: expected declaration specifiers or ‘...’ before
‘__builtin_object_size’
/Users/wincent/.rvm/rubies/ruby-1.9.1-p378/include/ruby-1.9.1/ruby/
missing.h:151: warning: conflicting types for built-in function
‘__builtin___snprintf_chk’
make: *** [objects/if_ruby.o] Error 1
Probably won't bother investigating further as this is not actually
"my itch to scratch", so to speak, as I've always been happy with Ruby
1.8.7.
Cheers,
Wincent
Wayne E. Seguin
Koudelka
I've successfully compiled MacVim with 1.9.1 under rvm.
Here are the config.mk values that worked for me:
RUBY = /Users/mikes/.rvm/bin/ruby-1.9.1-p378
RUBY_CFLAGS = -I/Users/mikes/.rvm/rubies/ruby-1.9.1-p378/include/
ruby-1.9.1 -I/Users/mikes/.rvm/rubies/ruby-1.9.1-p378/include/
ruby-1.9.1/i386-darwin10.3.1 -DRUBY_VERSION=19
RUBY_LIBS = -lruby-static -lpthread -ldl -lobjc -L/Users/mikes/.rvm/
rubies/ruby-1.9.1-p378/lib
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.
The diff: http://gist.github.com/394844
Going to go cry now.
--Mike
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
Wayne E. Seguin
Awesomely done!!! Thank you for this :)
~Wayne
björn
> Hey guys,
> I've successfully compiled MacVim with 1.9.1 under rvm.
>
> Here are the config.mk values that worked for me:
> RUBY = /Users/mikes/.rvm/bin/ruby-1.9.1-p378
> RUBY_SRC = if_ruby.c
> RUBY_OBJ = objects/if_ruby.o
> RUBY_PRO = if_ruby.pro
> RUBY_CFLAGS = -I/Users/mikes/.rvm/rubies/ruby-1.9.1-p378/include/
> ruby-1.9.1 -I/Users/mikes/.rvm/rubies/ruby-1.9.1-p378/include/
> ruby-1.9.1/i386-darwin10.3.1 -DRUBY_VERSION=19
> RUBY_LIBS = -lruby-static -lpthread -ldl -lobjc -L/Users/mikes/.rvm/
> rubies/ruby-1.9.1-p378/lib
>
> 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.
>
> The diff: http://gist.github.com/394844
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
Michael Shapiro
> 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.
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?
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
björn
> 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
björn
>
> 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
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. ( http://github.com/koudelka/macvim/commit/e550f312ee25696c4245fb9e2b58bfb0c78da05e )
--Mike
björn
>
> 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.)
Thanks,
Björn
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 (note that the repo is now at [1])?