なぜわざわざタイトルに「（2022年初頭版）」とつけたかというと、今われわれは混沌のさなかにいるからです。明日はどっちだ。
めちゃくちゃややこしいことに、現時点でRtoolsはRtools40とRtools42の2種類が存在します。 そして、細かいことを言ってさらにややこしくすれば、Rtools40には2つのバージョンが存在します。
- Rtools40: MSYS2をベースにいくつかパッチをあてたもの
- Rtools42: MXEというツールチェーンそのまま
- R 4.2用のツールチェーン（GCC 10 64bit:
${RTOOLS42_HOME}/x86_64-w64-mingw32.static.posix）と依存ライブラリを含む（ので重い。3GB越え...）
- R 4.2用のツールチェーン（GCC 10 64bit:
ということで、今のR-develをビルドできるツールには、Rtools40v2とRtools42の2種類があります。 Rのバグを検証するために開発版をビルドしようとしたらそれぞれ微妙にビルド方法が違ったのでメモ。
Rtools40v2
Rtools40v2は、今のCRAN公式ページからダウンロードできるものです。
こっちでビルドする場合は、今のRのビルドに使われているスクリプトがGitHubで管理されているのでこれを使います。
- （事前準備）MikTeXをインストール
- https://github.com/r-windows/r-baseをクローン
- Rtools Bashを開き、クローンしたディレクトリに移動
./quick-build.shを実行
でRのソースがダウンロードされてビルドが実行されます。
もしパッチをあてたい場合は、 ./quick-build.shで
# Add custom patches here: # patch -Np1 -i "${srcdir}/myfix.patch"
とコメントアウトされている部分があるので、ここをいじります。
例えば、https://github.com/wch/r-sourceをクローンしてソースコードをいじるとgit diffでパッチが吐き出せるので、それをfoo.patchとして適用するには以下のようにします
# これは別のターミナルで git diff > /path/to/r-windows/r-base/foo.patch
# Add custom patches here:の下にこの行を追加 patch -Np1 -i "${srcdir}/foo.patch"
ちなみに、./quick-build.shは毎回ソースコードをダウンロードしてきてゼロからビルドしなおすので、
何度も試すならrm -Rf R-develあたりの行をいじって、あと、最後にパッチを巻き戻すようにしておきましょう。
(cd R-devel && patch -Np1 --reverse -i ../foo.patch)
Rtools42
Rtools42は、今のところ以下からダウンロードできます。rtools42-4960-4926.exeみたいなファイル名になってるやつです。
これほんとに公式なの...？という感じですが、以前のブログでアナウンスされていた去年12月のツールチェーン切り替えはフェイントで、今はまだRtools40が使われているらしいです。まじでどういう状況なのか謎です。
で、こっちでビルドするには、↑のr-windows/r-baseは動かないので（同じツールチェーンのはずですが、たぶんパスが違うとかそういう理由で）、以下のドキュメントの「Building R from source using Rtools42」に従う必要があります。注意点として、さっきの「Rtools Bash」ではなくて「Rtools42 Bash」を使います（Rtools40とRtools42は共存できるので、どっちもインストールしてる場合はややこしい）
余談
なんでこんなことになってるんだ、と思って問い合わせたら、いろいろひどかった。 情報が断片的にしか入ってこないのでどっちが悪いのかよくわからないけど、メーリングリストとかGitHubのissueで険悪なやりとりがいくつかあり、 控えめに言って、健全な状態ではなさそう、と感じます。 何かできることあるんだろうか。
