はじめに
私が扱う特殊な環境のひとつに、mingw-w64でビルドしたVimと、msys2でビルドしたVimが共存している環境がある。
どちらも$HOMEを同じ場所にしているため、同一の.vimrc、runtimepathを見に行くようになっている。
このような環境で問題になるのは各環境用にビルドが必要なvimprocで、以前pathogenで管理していたときはそれぞれの環境でmakeを手動実行すればよかったのだが、dein.vimに乗り換えてからはそれだけでは済まなくなってしまった。
特殊な状況なので同一のことに悩まれている方は少ないかと思うが、ひとまず解決に至ったので記事にまとめることにする。
前提となる環境
下記の環境でVimを扱う場合を想定している。
- Windowsネイティブ環境:
mingw-w64でビルドしたVim、またはvim-jpで配布されているVim - msys2のシェル内:
vimパッケージのvim - mingw32/64のシェル内:
vimパッケージのvim
また、vimprocはTOMLに以下のように書いてあると想定する。
[[plugins]]
repo = 'Shougo/vimproc'
hook_post_update = '''
if dein#util#_is_windows()
let cmd = 'tools\\update-dll-mingw'
elseif dein#util#_is_cygwin()
let cmd = 'make -f make_cygwin.mak'
elseif executable('gmake')
let cmd = 'gmake'
else
let cmd = 'make'
endif
let g:dein#plugin.build = cmd
'''
問題点
1. どちらかのDLLしか作られない
前提とする環境だと2種類のDLL（Windows用のDLLとCygwin用のDLL）を作らなければならないのだが、この設定だとdein#install()やdein#update()した環境のDLLしか作られない。
DLLが作られなかった環境でdein#reinstall('vimproc')すればよいのかとも思ったが、「そんなプラグインはねーよ！」と怒られてしまった。
2. mingw32/64のシェルでVimを立ち上げるとvimprocのビルドに失敗する
前提とする環境の場合、WindowsネイティブなVimではなくmingw32/64でもmsysでビルドしたVimを利用するようにしている。dein#install()やdein#update()でvimprocのビルドが走るのだが、msysでビルドしたVimなのでdein#util#_is_cygwin()が1を返すこととなり、上記の設定だとmake -f make_cygwin.makが走ることとなる。
ただし、シェル環境自体はmingw32/64なので、このままだとビルドに失敗してしまう。
解決策
以下のようにTOMLを修正することでとりあえずうまく動くようになった。
[[plugins]]
repo = 'Shougo/vimproc'
hook_add = '''
if !filereadable(g:vimproc#dll_path)
call dein#call_hook('post_update')
let plug = dein#get('vimproc')
call dein#install#_each(plug.build, plug)
call dein#recache_runtimepath()
endif
'''
hook_post_update = '''
if dein#util#_is_windows()
let cmd = 'tools\\update-dll-mingw'
elseif dein#util#_is_cygwin()
let cmd = 'make -f make_cygwin.mak'
if $MSYSTEM == "MINGW32" || $MSYSTEM == "MINGW64"
let cmd = "MSYSTEM=MSYS bash --login -c 'cd " . g:dein#plugin.path . ";" . cmd . "'"
endif
elseif executable('gmake')
let cmd = 'gmake'
else
let cmd = 'make'
endif
let g:dein#plugin.build = cmd
'''
mingw32/64のシェルからmsysのVimが起動された場合はmsysのシェルからmakeを叩くようにしてみた。
さらに、hook_addフックでg:vimproc#dll_pathにファイルがあるかを調べ、なければビルドしてdein#recache_runtimepath()でキャッシュを再構築するようにしている。
このタイミングでdein#recache_runtimepath()して問題ないのかはよく調べていないが、今のところ問題なく動いているようだ。