ROOTのコンパイル
ROOT
ROOT a Data analysis Framework | ROOT a Data analysis Framework
をビルドしようと、cmake-gui を使ってみた。GUIでソース、ビルド用ディレクトリを指定して、さらにカスタム変数の調整もできてしまう、便利なもの。自前のプロジェクトを cmake 対応した時に、試してみて便利とおもいユーザーにすすめていた。
tar ball をダウンロードして、展開。cmake-gui でビルド用ディレクトリも作り、configure & generate。あとはビルドということで、
$ cmake --build ${BUILD_DIR}
とするが・・・・エラー。コンパイルの途中でエラー。compiledata.h がないよ、ってエラー。
検索してもそういうエラーは報告されていないので、????
原因: CMakeLists.txt の設定か、普通に cmake ${SOURCE_DIR} をすると、 include/comliledata.h を作る様子。cmake-gui を使う時にはビルド用ディレクトリから cmake を使っていないたか、エラーになってしまう。
対策:変数の設定をかんたんに行いたいのであれば ccmake のほうが良いでしょう。
ROOTを組み込んだプロジェクトをcmakeで管理する
ROOTライブラリを使うと色々便利なので多用している。最近は直接Makefileを書いたりautotoolsを使ったりするよりも、cmakeを使うのが良いらしい。ROOT自体も6.08からcmakeでのビルドがメインになった。
ならば、ROOTを使うプロジェクトもcmakeで管理すれば良いのでは?と、cmake対応をすすめてみた。autotoolsのかわり?的な気分ではじめてみたが、確かに良い感じ。ccmakeのお世話になる程ではないけれど、Makefileとの分離が程良くできている。autotoolsはMakefileのテンプレートを用意し環境に応じてMakefileを作るが、cmakeはNiniaを吐き出す事も出来る。いくつかのIDE用プロジェクトファイルも作ってくれるし、まさにビルド支援ツール。
色々な環境に対応したMODULEを使えば、マルチプラットフォーム対応への壁も低くなりそう。
標準的なLinuxであれば、今までMakefileにかけた圧倒的にビルド環境構築にかかる時間が短かくなる。build-in-sourceが非推奨なのも、バージョン管理システムとの親和性が良い。特に意識せずに別ディレクトリでのビルドが可能。
ROOT用の設定はFindROOT.cmakeを使えば一発。使い方は
https://root.cern.ch/how/integrate-root-my-project-cmake
こちらにまとまっています。知らずに中身を見ても使える程度の内容なので、cmake初学者には良い教材かも。
忘れないうちに、メモ。
忘れない内にメモ
Windows 用の X server について。今まで Xming、VcXsrv を使ってみた。諸般の事情から VcXsrv でルートウィンドウを表示しながら使っている。
今回、MobaXterm なるものを知った。無料版と有料版があり、無料版を試してみた。
そんなに悪くない。初心者にとってX serverを理解するのが既に壁になっていることを考えると、ターミナルと一緒になっている所がなお良いような気がする。PuTTYの設定をつかってSSHセッションを張ってくれるのも良い。
若干もたつくような気もしないでもないが、しばらく使ってみることにする。
セッション数の制限や、不必要なゲーム等を削除できる有料版も魅力的に思えてくるかも。
なにかレビューあるかしら?とサーフィン(死語?)していると、これを見つけた。
もう、全くその通り。MobaXtermの良いところを余すところなく紹介されています。敬服。
ようやく問題解決
2週間ほど前に仕事用Windows10デスクトップにトラブル発生。起動すると、ログイン画面の直前で真っ黒画面になって、くるくる回るステータスバーがまわり続ける。
セーフモードでなんとか起動してみたりすると、どうやらビデオボードまわりで問題発生の様子。GeForce 650 Ti を載せているのだけど、オンボードビデオからディスプレイに出力する分にはなんら問題なし。GeForceから出力すると、どうやらログイン画面までも到達せずに無限ループに陥っている。
グラフィックドライバの問題か?と、新しいドライバがでるまではオンボードビデオを使いましょうということで、ここ数日は過ごしてきた。ところが、オンボードビデオの場合に
- VcXsrv がつかえない
- BlueJeansテレビ会議を使うと、画像が描写されない
という問題が発生。オンボードビデオってこんなに貧弱なのか?とおもうが、そこまで貧弱とは思い難い。VcXsrvについては、リモートログインしているLinux Box を手元に移動して、ディスプレイをつけて、直接使う事で回避。テレビ会議については、他のPCで回避。
まったく理解のできない症状が出ていたのだけど、漸く問題を同定できた。しばらく前に、iPad Pro をサブディスプレイとして使えないだろうか?と導入した "Duet Display"
が諸悪の根源だった模様。これをアンインストールしてみたら、まったく問題無く GeForce 650 Ti 使えるし、試していないけど 上記の問題も解決しているでしょう。最新版は バージョン1-4-5-2で、インストールされていたのは 1-4-4-2。最新版なら問題は解決しているのだろうか・・・・・
※ 追記
最新版をインストールして再起動。今の所問題なく動作している。盲点だった・・・・
セカンドモニターにフルスクリーン表示(VcXsrv)
VcXsrc で作業をしているのだが、セカンドモニター上でフルスクリーン表示をしたい。(ルートレスが使えればなにも問題ないのに、ROOTとの相性問題がまだある)
XLaunch でルートレスを選択して軌道しても、ウィンドウはメインモニタ上。目的を果たすには、
- XLaunchで設定をファイルに保存
- 保存したファイルを適当なエディタで編集。(ASCIIのXMLファイル)
- 編集箇所: ExtraParams に "-screen 0 @2" を追加
設定ファイルを保存し、ダブルクリック。セカンドモニタにフルスクリーン表示されているのでは?
参考:
Coreファイル on Fedora system
随分久しぶりのブログ。なんとなく、インターフェースも改良されているような気がしなくもない。
Fedora 24 上でC++ベースのアプリケーションを作っている。といっても、随分前に作ったものを再利用しようとして手をだしてみた。とある事情により共用ライブラリからstatic なものに変更していると、Abort!!
Coreファイルをみてみたいのだけど、
$ ulimit -c unlimited
してもコアファイルが生成されない。いろいろ検索してみると、どうやら「問題の報告」システムに統合されているのが理由のようだ。coreファイルを吐きながら、バグレポートシステムにも渡すように設定できそう。
今回は、問題の起きている場所がわかれば良くて、デバッガのお世話になるほどでもない。なので、バグレポートシステムをつかってみる事にした。アプリケーションがアボートしたら、「問題の報告」ツールで詳細を確認。必要な情報は詳細にあるので、一件落着。
便利なような、便利でないような・・・・
どうしても気に障る言葉「近しい」
最近「近しい」の使い方が気に障ってしかたない。単に「近い」と書けば良いのに、「近しい」って書いてある。割合としては一割に満たないと思うのだが、数年前はもっと少なかったような気がする。(気になり出すしきい値を超えたのかもしれないし、繰り返しの結果しきい値が減少してしまったのかもしれない)
はじめ「近しい」という表現を見た時に、その背景がまったく理解できなかった。そもそも「近しい」ってなんぞ?というレベル。私の国語の能力による所だとおもう。頻繁に目につくようになってさらに疑念は膨らみ、「もしかしたらわしが知らんだけで、『近しい』って用法があるかも?」と、その段階にいたり漸く調べる事に。
言葉としてはいわゆる『親しい』ということ。これは「したしい」とも「ちかしい」とも読む。後者は『近しい』でも良いわけ。なるほど『親しい』ということね、と合点がいったわけなんだが、それじゃあもともと気になっていた問題は?というと、例えばある値が何か別の値に「近い」ときに「近しい値」と表現されている。
ネットを漁ってみると、どうやら最近全国的に広がっているネットスラング的なもののようだ。どこかのローカルルールとして利用されていたもののような記述もあるが、真偽のほどは知らず、なんだかしらんが感染が広がっている。
一つの理由として、ある種の婉曲表現として誤用が広がっているのでは?という指摘も受けた。単に「近い」というのは直接的すぎて、「近しい」ということでその状態を表現したいのだとか。そもそもの発端に立ち返って確認してみると、さもありなんという気もしてくる。
『遠い』とか『離れた』とか、逆のパターンはどうするのだろう?