Recently some vim plugins use if_lua for performance issues because Vim script is not so fast. For example Shougo's neocomplete.vim[1] shows better performance thanks to if_lua.
According to some benchmark results LuaJIT looks much faster than Lua and is fully compatible to Lua 5.1.[2][3]
So that we would get more performance advantage by using LuaJIT instead of Lua.
On Windows just replacing Lua's dll with LuaJIT's dll in Vim directory seems to work as expected without rebuilding vim in the case of dynamic link. Now LuaJIT bundled vim binary for Windows is distributed by kaoriya.[4]
However linking vim with LuaJIT on Unix like OS requires some works in configure and build process because library names and directory path of LuaJIT are slightly different from Lua. And LuaJIT requires special link options on Mac OS X. It might not easy for beginners.
It would be nice if configure would prepare for LuaJIT automatically so that users who want to use LuaJIT could easily build Vim with LuaJIT.
For this purpose I added a new configure option `--with-luajit`.
Here is a patch. This changes only configure.
https://gist.github.com/shirosaki/5663617/
When adding `--enable-luainterp --with-luajit` as configure option, configure tries to use LuaJIT instead of Lua .
Just with `--enable-luainterp` (without --with-luajit) configure tries to use Lua as before.
In addition I fixed an issue that build with `--enable-luainterp=dynamic` doesn't work properly with Lua on Mac OS X since shared library extension on Mac OS X is *.dylib while *.so on Linux.
Some vim users in Japan are interested in this fix and testing.[5]
I've tested this on Mac OS X, Ubuntu 13.04 and CentOS 6.4 with latest vim 7.3 and it seems to work.
Install instructions with LuaJIT:
Ubuntu:
$ sudo apt-get install luajit libluajit-5.1
$ cd vim_source_directory
$ curl https://gist.github.com/shirosaki/5663617/raw | patch -p1
$ ./configure --with-features=huge --enable-luainterp --with-luajit
$ make
$ sudo make install
Mac OS X with Homebrew:
$ brew install luajit
$ cd vim_source_directory
$ curl https://gist.github.com/shirosaki/5663617/raw | patch -p1
$ ./configure --with-features=huge --enable-luainterp --with-luajit --with-lua-prefix=/usr/local
$ make
$ sudo make install
[1] https://github.com/Shougo/neocomplete.vim
[2] http://luajit.org/luajit.html
[3] https://github.com/vim-jp/issues/issues/48#issuecomment-15355516
[4] http://www.kaoriya.net/news/2013/05/19/
[5] https://github.com/vim-jp/issues/issues/348
Thanks,
Hiroshi Shirosaki
If lua executable is not exist in the PATH and configure cannot find liblua.so, strange library name `liblua.so.` (end with .) is used in the case of dynamic loading. It occurs even if I build Vim without luajit patch.
$ ./configure --with-features=huge --enable-luainterp=dynamic --with-lua-prefix=/usr/local
$ make
(snip)
gcc -c -I. -Iproto -DHAVE_CONFIG_H -DMACOS_X_UNIX -no-cpp-precomp -g -O2
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
-DDYNAMIC_LUA_DLL=\"liblua.so.\" -I/usr/local/include -o objects/if_lua.o if_lua.c
I added some fixes for the case where lua or luajit executable is not exist in the PATH.
configure can fail or use default name with dynamic if a valid library name cannot be found when static or dynamic linking.
I've added some document in Makefile.
Here is updated patch.
https://gist.github.com/shirosaki/5663617
Hi Bram,
As I said before current Vim 7.4a has two bugs of if_lua configure with dynamic loading:
1) *.so is used as library name on Mac OS X whille *.dylib is correct on Mac OS X
2) -DDYNAMIC_LUA_DLL=\"liblua.so.\" is used (end with . ) If lua executable is not exist in the PATH and configure cannot find liblua.so
Should these bugs be fixed with Vim 7.4a?
If we will create only bug fix patch without LuaJIT support, then the bug fix patch will be accepted before 7.4 release?
Thank you.
--
Hiroshi Shirosaki