#1

先日の投稿でgem install berkshelfは罠であると切って捨てたんだけれども、結局ビルド出来ないまま終わったのはなんかちょっと悔しいなあ、と少し引っかかってはいた。

で今日OS Xにberkshelf入れてて、こっちはさすがにメモリあるから大丈夫だろうとgem install berkshelfやって、どの位メモリ食うかなあとアクティビティモニタ眺めてたらなんか思ってたより食ってない。
あれって少し考えたらもしかしてgccよりClangの方がメモリ食わないんじゃないかという可能性に辿り着いた。

#2
なのでさっそくAWSにsudo yum install clang clang-devel。
んでgemするときにCC=clang CXX=clang++ってつければconfigureが勝手にClang使ってくれる。

そしてberkshelfが入らない元凶、メモリ大食らいdep-selector-libgecodeを入れるべく、
sudo CC=clang CXX=clang++ gem install -V dep-selector-libgecode
とやってみるも残念ながら失敗。

#3
というのもこのdep-selector-libgecode、ただでさえやたらメモリ食うのにextconf.rb見ればmake -j 5とか富豪なことやってるせいでClangプロセスが並行して5つも立ち上がる。あほか。

なのでこれをどうにかしないとなあと色々考え試した末、makeコマンドを改ざんすることにした。

make

#!/bin/env ruby

puts "---this is ikasama make---"
arg = ARGV
arg = [] if arg == ["-j", "5"]
system("/usr/bin/make #{arg.join(' ')}")

これをどっか適当なところにおいてmakeって名前にして、PATH=`pwd`:$PATHってやればこれを優先して実行するようなって、make -j 5が来たら握りつぶすようなる。

#4
こうして奴を倒す武器は揃った。満を持して
sudo PATH=`pwd`:$PATH CC=clang CXX=clang++ gem install -V dep-selector-libgecode
を実行。topで見ればちゃんとClangプロセスが1つなのが確認できる。

そして割りと長い時間待った所、画面に1 gem installed！
みごとdep-selector-libgecodeに打ち勝ちそのままsudo gem install berkshelfもきっちり成功。こうしてメモリ1G、スワップ0のmicroインスタンスでもberkshelfをビルドすることが出来た。

#おまけ
make詐称とかしてないでdep-selector-libgecodeのmake -j 5外したプルリク投げるのが正道だろ、と思って投げようとしたらすでに同様のプルリクが飛んでた。さっさとマージして欲しいです。