MacBook Pro 15inch 2017
今年の7月にMacBook Pro 2017の15インチを購入しました。SSDだけ256GB→512GBにして30万円。「高っ!」と思いながらも、新しいプライベート開発マシンがほしくて買いました。その感想を適当に書いていこうと思います。
サマリ
- 結論
- やっぱりMacは良い
- 良かった点
- TouchBarは割と使いやすい
- キーボードは軽くて打ちやすい
- 15インチでもすごく軽いので持ち運びもOK
- 気に入らない点
- 耐久性に欠けるキーボード?
- バッテリーは持ちが良くない
筆者の使い方
- 仕事はLet's Note
- 自宅ではこのMacBook Pro
- 主に休日に趣味のプログラミングで利用
- 1日に3-4時間はタイピングしていると思う
- Macを触るのは4年ぶり
久々にMacを触って
私はMacを使っていたのはSnow Leopardの頃なので、実に4年ぶりにMacを使いました。その4年間はずっとWin7, Win8, Win10, Ubuntuなどを使っていました。 久々にMacを触った感想ですが、 ”めちゃくちゃ良いOSだな” という感じです!いや、最近のWin10も頑張っててすごく使いやすいのはもちろんわかってます。ですが、環境設定のやりやすさ、ソフトウェアの入れ方、細かい美しさなどは、さすがMacという感じです。
また、これは開発者の意見ではありますが、ターミナルが使えるのはすごくいいですね。Win10もBash on Windowsが使えるようになっているのですが、やはりMacのターミナルの方が使いやすいですね。zsh入れて、いい感じな開発環境にしちゃってます!
TouchBar
かなり気にって使っています。同僚から「使いにくい、あんなのいらないよ」と聞いていたので不安だったのですが、私はいいなーというポジティブな印象です。
- 音量や輝度を指でアナログ的に調整できるのはすごく便利
- Safariを使えばYoutubeのシークバーがTouchBarに表示されて、これも便利
- TouchIDが使えると、パスワードをいちいち入力しなくて良い
- ESC、ファンクションキーの入力はそんなに気にならない
- 普段からあまり使ってないから
- vimでもESC使わないし
キーボード
これは良い点と悪い点がある感じですね。まず良いのは、非常に入力が軽くなったと思います。最初はなかなか慣れませんが、慣れてくると”あまり手のパワーを使わなくても入力できるんだなー”と実感できました。
一方で、バタフライキーボードは繊細な構造をしているらしく、ちょっと壊れやすい印象です。と言いますのも、どうもチャタリングをよく起こしているように感じています。実はnとmのキーが、ときどき1回のタイプで2回入力になって困った時期がありました。これがプログラミングしているときに発生するとすごくイライラするんですよね…
import React from 'react' // 正しい入力 immport React fromm 'react' // チャタリングが発生して、こんな感じになっていることも…
Genius Barに言って、キートップの入れ替えと掃除をしてもらいました。そうすると発生頻度はかなり減少しました。それでもときどき発生します。保証期間はまだあるので、もう少し様子を見てみることにしてます。
軽い
これは本当にびっくりしてます。以前はSnow Leopard時代の15インチを使っていたのですが、すごく重くて持ち運びがけっこう億劫になっていました。でも今の15インチは すごく軽くて、持ち運びもできちゃいます。これはかなりサイコーです。
ただ、バッテリーの持ちはあまりよくない気がしていています。バッテリーの大きさを少なくして、その分が軽くなったという具合みたいですね。私は軽いという方が体験として大きい気がしているので満足しています。
USB Type C
これはよくわからないです。充電で使うだけで、外部ディスプレイにつなげる事などがないので。
最後に
久々にMacを使っているので、やっぱりMacは良いなという感じがしています。 周囲では”Macは面白みがなくなった”と言っている人がいますが、それはMacに慣れすぎちゃっただけじゃないかなーと思いっています。
鉄血のオルフェンズから学んだリーダーシップ
機動戦士ガンダム 鉄血のオルフェンズが完結してから約半年といったところでしょうか。最終回に近づくに連れてハラハラしながら視聴していたのを覚えています。自分の中では、歴代で見たアニメの中でトップ5に入るくらいの評価をしています。ただ、会社の後輩たちに評価を聞いてみると「いまいちでしたよね」と辛口なコメントでした。まぁ評価は人それぞれだからなー、と思ったら、Amazon Primeでの評価も散々なことになっていてビックリしました。
なぜ自分は鉄血のオルフェンズという作品に対してここまで熱い思い入れがあるのか、ちょっと考えてみて文字に起こしてみることにします。
まだ鉄血のオルフェンズを視聴されていない方は、ネタバレ注意です
サマリ
- 作品で描かれているリーダーシップに共感した
- オルガはリーダーとして選択を誤ってしまった
- それでも自分はオルガのようなリーダーを望むし、自分もそうありたいと思った
なぜここまで感動したのか
結論を先に書くと、自分が現実で置かれていた状況とすごくリンクするものがあったからです。ちょうどオルフェンズを視聴していた時期、自分はあるエンジニアリングチームのマネジャーになったばかりでした。
どのようにマネジャーとして振る舞うべきか考えていたときに、オルフェンズを視聴していると「このアニメはリーダーシップをテーマにしているのではないか?」と思い始めました。今までの自分のガンダムシリーズの視聴と違う見方が出てきました。特に鉄華団のオルガ・イツカのリーダーシップにはすごく共感してしまい、自分のエンジニアのマネジメントと照らし合わせて見ていると、震えが出ました。
ちなみに、鉄血のオルフェンズとリーダーシップの関連性をすでに先行して書いてらっしゃる方がいましたので、そちらのリンクも貼らせていただきます。
登場するリーダーシップ
リーダーポジションの人物は何名か登場するのですが、物語のメインキャラクターである以下の2人について書いてみることにします。
私が物語を見ていて思った2人の違いは、問題の解決方法の違いです。
- オルガ
- 物事をやり遂げるという強い意志を持っている
- その障害となるものは排除するという気が強い
- クーデリア
- 物事をやり遂げるという強い意志を持っている
- ときには妥協もする、調和を大切にしながら目的を達成するという考え
両者、強い信念を持っていて、自らの考えを曲げようとはしない。これはリーダーに必要な要素です。違いポイントは、壁にぶつかったときの対処方法が違うというところです。
オルガは非常にアグレッシブなタイプのリーダーです。常に上を目指し続けますし、その障害となる問題は排除する(武力でなんとかする)傾向があります。実際、鉄華団はそうやって大きくなった組織であり、その成功体験が彼にはあったからです。 しかし、その方法では上手く行かなくなってくる時期が突然に訪れます。物語が最後になるにつれて、彼は自らの選択が本当に正しかったのかというプレッシャーにひどく悩まされてしまいます。彼の決断の結果、鉄華団はとてつもない強大な敵を作ってしまい、チームは破滅に追い込まれてしまいます。
一方のクーデリアですが、彼女も大きな野望を持っています。野望を達成するためには、彼女がいま持っている地位や権力など、圧倒的に足りない状況でした。なので彼女は、最初は鉄華団という武力に頼り目的を達成しようとします。鉄華団とはウィン・ウィンの関係にあり、これは上手くことを運びました。 最初は武力を許容していた彼女ですが、ある程度の権力を持つと、武力以外のやり方で物事を成し遂げようと様々な施策を試みていきます。なるべく争いは避け、なるべく敵を作らず(誰からも嫌われず)に事業の拡大を目指しました。
クーデリアが理想のリーダー
間違いなくクーデリアは理想的なリーダーだったと思います。彼女の行動は周りから支持され、最終的に目的を達成できたのはオルガではなくクーデリアでした(※)。彼女が目的を達成できたのは以下のリーダーとしての素養があったからだと考えています。
- 周りの状況に合わせて柔軟に行動を変える
- 相手に共感する
- そのため、たくさんの人が協力をしてくれる
大きな目標は、1人では達成できません。彼女は周りからの支持を得られる行動をしていました。そこがオルガとは違ったポイントでした。
※オルガは「すでに目的は達成していた」と気づいて亡くなります。しかし鉄華団の最も危ういタイミングで逝ってしまった彼は、その問題を解決することができなかったので、私は彼の目的は達成できなかったと解釈しています。
それでもオルガの方がいい
アニメを見ていて思っていたことがあります。
- オルガのやり方は良くないよな…
- これ絶対にあとで失敗しそう…
- クーデリアは皆が望むリーダーシップを発揮している
- 彼女は成功するかも?
実際に上記の予想は当たってしまい、なんとも切ない最終回を迎えてしまいます。オルガの行動は攻撃的だったし、多くの敵を作ってしまったのは間違いありません。反して、クーデリアは理想的なリーダーシップを貫き、夢を実現しました。しかし、かといってクーデリアのようなリーダーが本当に良いかと言うと、私は以下のように思うのです。
クーデリアのように周りに気を使って自らが犠牲になる。好きな男性も譲ってしまう。 そんなリーダーに誰がなりたいんだろう?
リーダーも1人の人間だし、個人としてやりたいこと、達成したい幸せもあると思います。 エンジニアリングのマネジメントに関してもそうです。自分よりコードが書けないメンバーのマネジメントをして、自分は技術から遠ざかっていく日々。チームのために自らを犠牲にして仕事をやるのは本当に正しいのかと。
オルガは結果として失敗しますが、彼の行動は多くの人を惹きつけ、鉄華団の結成という大きい成果をもたらしました。周りを気にせず自分のために行動する、その姿はマネジャーとして大きく憧れるところがありました。
以上、鉄血のオルフェンズを見て思った次第でした。
1-on-1を半年くらいやったので、振り返ってみる
今年の初めに5人ほどのチームのマネジャーになりました。その時、1-on-1というマネジメント術があることを知ったばかりで、すごく試してみたいというモチベーションがあり、やってみることにしました。その知見などを共有できればと思います。
1-on-1とは?
私がやってきた1-on-1は以下のとおりです。
- 隔週(ときどき毎週)で部下と1対1で面談を実施する
- 1回の面談は30分〜1時間くらいの長さ
- 対話するより、話を聞いてあげる
いろんなブログポストや書籍を読んだのですが、それぞれで1-on-1の定義が微妙に違ったりします。そのあたりはマネジャーの好みや、使える時間もあるので、自分にあった1-on-1をすればいいんじゃないかなーと思っています。毎週or隔週は、その部下のモチベーションなどによって、「あ、この人とは来週もやったほうがいいな」みたいな感じで決めていました。
ちなみに、1-on-1について参考にしたのは以下です。
具体的な手法の参考
- 書籍
- ヤフーの1on1―部下を成長させるコミュニケーションの技法(ダイヤモンド社)
- SlideShare
”ヤフーの1on1”は詳細な手法を取り扱っている数少ない書籍だと思います。すごくおすすめです。もっとこの本が早く発売されてたら、最初から上手くやれてたのかなーと思ったり。
その他、ちょろっと触れられているもの
1-on-1のために読む書籍ではないが、マネジメント観点だと面白いので共有。
- 書籍
- High Output Management(日経BP社)
- ネットの情報
メリットとデメリット
いきなり本題ですが、メリットとデメリットを記載します。正直、メリットのほうが多い気がしていて、デメリットはさほど気にならないです。
メリット
大きく3つのメリットがあったので、それぞれをかんたんに説明します。
- チームの問題がわかる
- 自分のマネジメントのフィードバックをもらえる
- 飲みに行かなくてもコミュニケーションが活発になる
1.チームの問題がわかる
一番のメリットはこれです。話を聞いていると、「何を不安に思っているのか」「なんでやる気をなくしているのか」そういったマネジメント的に重要なことが手に取るようにわかるようになってきます。
任天堂の岩田聡さんが以下の発言をされていますが、まさにこの通りだなと思っています。
「人は逆さにして振らないと こんなにもモノをいえないのか」 とあらためて思いました。
いろんな人に面談すればするほど、 わたしはいろんなことがわかりまして、 そのなかから どういうふうに 組織を作りなおして、 どういう運営をしたらよくて、 なにがみんなのやる気を ひきだすことに役にたっていて、 なにがみんなの やる気を阻害しているのかとか…… すべて見えてくるんですね。
- 社長に学べ
- →こちらのNo.10です
2.自分のマネジメントのフィードバックをもらえる
マネジャーというポジションにもなると、フィードバックを伝える機会はあるものの、逆にもらう機会は少なくなります。私は以下のように質問をして、部下からフィードバックをもらうようにしていました。
- マネジャーとして、私ができることはある?
- 私に対して何かフィードバックある?
- 今のチームをどう思う?
ただし、後ほど記載するのですが、1-on-1をはじめたばかりの頃は、まだ部下は警戒をしている可能性があるので、率直なフィードバックはもらえていない可能性があります。
3.飲みに行かなくてもコミュニケーションが活発になる
今まで部下と仲良くなるためには「飲みに行って、腹を割って話すか」みたいに思っていたのですが、そんなことはなくなりました。むしろ今までの考えだと、お酒が苦手なメンバーとは仲良くなれてなかったんだなぁと、強く反省をする機会にもなれました。
デメリット
- 時間が必要になる
- 部下の数によっては、1-on-1実施はそこそこの工数になってしまう
- →あらかじめ1-on-1の時間を考慮して自身のタスク管理が必要です。
- 優しくあろうとしてしまう
- 部下の率直な気持ちを聞けることで、部下に嫌われないように振る舞いがちになる
- →優しくなりすぎて、マネジャー側がほいほい仕事を巻き取ることがないように注意
- →部下がやりたい仕事と、チームとしてやらなきゃいけない仕事、あきらかに後者が優先なので
1-on-1体験記
実際に1-on-1をやってみてからの苦労話などを共有します。
最初の一歩
私の場合は、マネジャーを前任から引き継ぐ形だったので、そのタイミングで部下全員と面談を実施しました。そのときに、「この面談ですけど、隔週くらいでやらせてください」と伝えて1-on-1につなげました。なので、かなり違和感はなく1-on-1を導入できたのではないかと考えています。
最初の1-2ヶ月
マネジャーとして、精神的にぐっと耐える時期だと思います。なぜなら、1-on-1をしているからといって、すぐに部下がいろいろと話しをしてくれるわけではないからです。なかなか本音を言ってくれない部下も何人かいました。このときに「1-on-1やめようかな」と思ってしまうとダメだと思います。根気よく続けていくことが、マネジャーの仕事になります。個人的には3ヶ月を過ぎたあたりで、成果が出てきたように感じました。
話すことがない部下には?
適当に雑談をしていました。こちらも最初は相手の趣味や思考などがわからないため、雑談のテーマは何がいいかわからないと思います。しばらく1-on-1を続けると、どんなことに興味があるのかがわかってくるので、雑談はそう困らないです。
まとめ
1-on-1はチームを成長させるために非常によいマネジメント手法だと今では考えています。今後も続けていこうと思っています。
ヤフーの1on1―――部下を成長させるコミュニケーションの技法
- 作者: 本間浩輔
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2017/03/25
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
HIGH OUTPUT MANAGEMENT(ハイアウトプット マネジメント) 人を育て、成果を最大にするマネジメント
- 作者: アンドリュー・S・グローブ,ベン・ホロウィッツ,小林薫
- 出版社/メーカー: 日経BP社
- 発売日: 2017/01/11
- メディア: 単行本
- この商品を含むブログ (3件) を見る
つぶやき
新しいMacBook Proでこのブログを書いてますが、キーボードがカパカパして微妙だなぁ…
MNISTチュートリアルを実行するときにdateutilのバグを踏んだ
TensorflowのMNISTチュートリアルを実行しようとしたときにエラーで落ちた。 たぶん同じバグを踏む人は多いと思うので、メモがてら共有。
発生条件
どうやらチュートリアル用のMNISTサンプルをimportするときに発生しているみたい。
from tensorflow.examples.tutorials.mnist import input_data
自分のPython環境はAnacondaです。
$ python -V Python 3.5.2 :: Anaconda custom (64-bit)
エラー内容
ちょっと長いので省略して書くが、以下のような内容で落ちる。
$ python main.py I tensorflow/stream_executor/dso_loader.cc:128] successfully opened CUDA library libcublas.so locally I tensorflow/stream_executor/dso_loader.cc:128] successfully opened CUDA library libcudnn.so locally I tensorflow/stream_executor/dso_loader.cc:128] successfully opened CUDA library libcufft.so locally I tensorflow/stream_executor/dso_loader.cc:128] successfully opened CUDA library libcuda.so.1 locally I tensorflow/stream_executor/dso_loader.cc:128] successfully opened CUDA library libcurand.so locally Traceback (most recent call last): File "main.py", line 2, in <module> from tensorflow.examples.tutorials.mnist import input_data File "/home/hogehoge/.pyenv/versions/anaconda3-4.1.1/lib/python3.5/site-packages/tensorflow/examples/tutorials/mnist/__init__.py", line 21, in <module> from tensorflow.examples.tutorials.mnist import input_data File "/home/hogehoge/.pyenv/versions/anaconda3-4.1.1/lib/python3.5/site-packages/tensorflow/examples/tutorials/mnist/input_data.py", line 29, in <module> #省略 File "/home/hogehoge/.pyenv/versions/anaconda3-4.1.1/lib/python3.5/site-packages/pandas/__init__.py", line 22, in <module> from pandas.compat.numpy import * File "/home/hogehoge/.pyenv/versions/anaconda3-4.1.1/lib/python3.5/site-packages/pandas/compat/__init__.py", line 350, in <module> from dateutil import parser as _date_parser File "/home/hogehoge/.pyenv/versions/anaconda3-4.1.1/lib/python3.5/site-packages/dateutil/parser.py", line 158 l.append("%s=%s" % (attr, `value`))
ググったらdateutilのバグみたい
ここに、「それはdateutilのバグだね」って書いてあった
Error when importing pandas in Python 3 · Issue #551 · hashdist/hashstack · GitHub
dateutilをアップグレードしたら直った
直し方は単純で、アップグレードしてやればよい。これで終了。
$ conda install -c conda-forge python-dateutil=2.6.0
CUDAのサンプルで"cannot find -lGL"でハマった件
ちょっとハマった、というか「しょーもな」って感じのポイントなんだけど。いちおうメモしておく。
CUDAをインストールしたら、まずはsampleを動かしてみたくなるんだけど、nbodyをビルドしようとしたら以下のエラーが発生した。OSはUbuntu 14.04.5、CUDAは7.5。
$ cd /usr/local/cuda/samples/5_Simulations/nbody $ make >>> WARNING - libGLU.so not found, refer to CUDA Getting Started Guide for how to find and install them. <<< >>> WARNING - libX11.so not found, refer to CUDA Getting Started Guide for how to find and install them. <<< >>> WARNING - gl.h not found, refer to CUDA Getting Started Guide for how to find and install them. <<< >>> WARNING - glu.h not found, refer to CUDA Getting Started Guide for how to find and install them. <<< >>> WARNING - Xlib.h not found, refer to CUDA Getting Started Guide for how to find and install them. <<<
はーん。OpenGL関連がないのかー。
なのでapt-getで必要そうなライブラリをインストールする。
$ sudo apt-get install freeglut3-dev libglu1-mesa-dev
これでmakeし直したらいいと思ったら、「libGLなんて見つからないよ」とエラーが出てきた。
$ sudo make "/usr/local/cuda-7.5"/bin/nvcc -ccbin g++ -I../../common/inc -m64 -ftz=true -gencode arch=compute_20,code=sm_20 -gencode arch=compute_30,code=sm_30 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52 -gencode arch=compute_52,code=compute_52 -o bodysystemcuda.o -c bodysystemcuda.cu "/usr/local/cuda-7.5"/bin/nvcc -ccbin g++ -I../../common/inc -m64 -ftz=true -gencode arch=compute_20,code=sm_20 -gencode arch=compute_30,code=sm_30 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52 -gencode arch=compute_52,code=compute_52 -o nbody.o -c nbody.cpp "/usr/local/cuda-7.5"/bin/nvcc -ccbin g++ -I../../common/inc -m64 -ftz=true -gencode arch=compute_20,code=sm_20 -gencode arch=compute_30,code=sm_30 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52 -gencode arch=compute_52,code=compute_52 -o render_particles.o -c render_particles.cpp "/usr/local/cuda-7.5"/bin/nvcc -ccbin g++ -m64 -gencode arch=compute_20,code=sm_20 -gencode arch=compute_30,code=sm_30 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52 -gencode arch=compute_52,code=compute_52 -o nbody bodysystemcuda.o nbody.o render_particles.o -L../../common/lib/linux/x86_64 -L/usr/lib/"nvidia-352" -lGL -lGLU -lX11 -lglut -lGLEW /usr/bin/ld: cannot find -lGL collect2: error: ld returned 1 exit status make: *** [nbody] Error 1
いや、そんなはずはない。さっきインストールしたでしょ?
と思ってlocaleとか使って調べたら、なんか変なシンボリックリンクが貼ってあってあるだけだった。
ブログだと色がついてないからわかりにくいと思うけど、libGL.soの参照先が存在しないファイルを指定してる。
#同ディレクトリに「libGL.so.1.2.0」はない
#素のUbuntuターミナルだと赤色になっていると思う。
$ ll /usr/lib/x86_64-linux-gnu/mesa/ total 76 drwxr-xr-x 2 root root 4096 9月 25 00:16 ./ drwxr-xr-x 95 root root 69632 9月 25 00:16 ../ -rw-r--r-- 1 root root 31 7月 1 05:45 ld.so.conf lrwxrwxrwx 1 root root 14 1月 13 2016 libGL.so -> libGL.so.1.2.0
下記の方法がよいかわかんないけど、libGLがちゃんとある場所にシンボリックリンクを指定してあげることにした。
$ cd /usr/lib $ sudo ln -s /usr/lib/x86_64-linux-gnu/libGL.so.1.0.0 libGL.so
これでビルドしたら上手くいった。
やっぱりGPGPUと言えばこのsampleですよねー。
$ sudo make "/usr/local/cuda-7.5"/bin/nvcc -ccbin g++ -m64 -gencode arch=compute_20,code=sm_20 -gencode arch=compute_30,code=sm_30 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52 -gencode arch=compute_52,code=compute_52 -o nbody bodysystemcuda.o nbody.o render_particles.o -L../../common/lib/linux/x86_64 -L/usr/lib/"nvidia-352" -lGL -lGLU -lX11 -lglut -lGLEW mkdir -p ../../bin/x86_64/linux/release cp nbody ../../bin/x86_64/linux/release $ ./nbody Run "nbody -benchmark [-numbodies=<numBodies>]" to measure performance. -fullscreen (run n-body simulation in fullscreen mode) -fp64 (use double precision floating point values for simulation) -hostmem (stores simulation data in host memory) -benchmark (run benchmark to measure performance) -numbodies=<N> (number of bodies (>= 1) to run in simulation) -device=<d> (where d=0,1,2.... for the CUDA device to use) -numdevices=<i> (where i=(number of CUDA devices > 0) to use for simulation) -compare (compares simulation results running once on the default GPU and once on the CPU) -cpu (run n-body simulation on the CPU) -tipsy=<file.bin> (load a tipsy model file for simulation) NOTE: The CUDA Samples are not meant for performance measurements. Results may vary when GPU Boost is enabled. > Windowed mode > Simulation data stored in video memory > Single precision floating point simulation > 1 Devices used for simulation > Compute 5.2 CUDA device: [GeForce GTX 980 Ti]
LLVM3.9をインストールする
冬コミのネタなんかないかなーと思ってて、「そういえばLLVM3.9出たのかー」と思ってとりあえずインストールしてみた。ちなみにOSはUbuntu14.04を使ったよ。
LLVM Download Page
↑ここから「LLVM source code」をダウンロードしてくる。
いつも通りcmake使ってビルドするかー、と思ったら最新のcmakeが必要になってた。
$ mkdir build $ cd build/ $ cmake -D CMAKE_INSTALL_PREFIX=/usr/local/llvm-3.9 .. CMake Error at CMakeLists.txt:3 (cmake_minimum_required): CMake 3.4.3 or higher is required. You are running version 2.8.12.2 -- Configuring incomplete, errors occurred! $ cmake --version cmake version 2.8.12.2
まぁ仕方ないのでcmakeの最新版を取得して、ビルドとインストールした。
#cmakeも今は最新が3.6.2とかなんだ。へぇ〜。
Download | CMake
↑ここから「cmake-3.6.2.tar.gz」をクリックして落とす。
$ cd cmake-3.6.2 $ ./configure $ make -j4 $ sudo make install
割とすんなりインストールできた。で、LLVMのビルドに再チャレンジ。
$ cmake -D CMAKE_INSTALL_PREFIX=/usr/local/llvm-3.9 .. -- No build type selected, default to Debug -- The C compiler identification is GNU 4.8.4 -- The CXX compiler identification is GNU 4.8.4 -- The ASM compiler identification is GNU -- Found assembler: /usr/bin/cc
上手くいったみたい。あとはmakeするだけ。
#なんか最後の98%くらいで「やけにChrome重いなー」と思ったら、
#メモリ使用率が13GBとかなってビビった。
$ make -j4
make終わったしあとはinstallだけだなと思ったら、HDDの容量が少なくなっててインストールできないことに気づいた!!!
たぶんinstallしたら10GBくらい使うのかな?ビルドしたディレクトリも13GBになってた。1TBのHDDに交換したら再チャレンジするか。。。
$ du -d 1 --block-size=M . 263M ./cmake-3.6.2 13875M ./llvm-3.9.0.src