C 言語を読み書きできないけど neovim のソースコードを読む (1)

最近 neovim というプロジェクトが話題になりました。vim をめっちゃリファクタリングしよう!っていうプロジェクトです。日頃から vim は使っているし、個人的にかなり興味のあるプロジェクトなので、なんとかして貢献できないかなーと思ってます。

でも僕は C 言語が読み書きできないので、ほとんどが C で作られている neovim ( vim もそうだけど)に貢献するためにはそれを身につける必要があります。なのでとりあえず neovim のソースを検索しまくりながら読んで活路を見出そうとしています。

どのように読み進めていくのかは決めていませんが、思いついたままの順番で読んでいきます。記事に残す粒度も適当です。

僕のスペック

  • 普段触っているのは PHPRuby で、 C を書いたことあるのは Hello World に毛が生えたくらい。
  • C はコンパイルが必要なことは知ってるけど、コンパイルがどのような工程で行われてるのかは知らない。
  • ターミナルだけでサーバーはある程度扱えるけど、コマンドそれぞれがどのような仕組みで動いているのかはあまり知らない。

configure について

  • configure は autotools というツール群によって作ることができます。

C 言語のヘッダーファイルの役割

  • ソースファイルに対して情報提供をする。
  • 理由は分からないけど、ヘッダーファイルにはクラスの宣言を書き、クラスの実装はソースコードに書く作法らしい。

lua

moon script

UINT32_t

  • 変数の型。

typedef

  • 既にあるデータ型に新しい名前をつけることができる。

struct

  • 構造体の宣言。

#ifdef

  • 条件コンパイルと呼ばれるもので、処理を分岐させることができる。

isatty 関数

  • ターミナルかどうかをチェックする標準関数。

register 指定子

  • コンパイラに対してこの指定子を付けた変数へのアクセスを最大限速くしてもらうよう宣言する。

バッファリング

  • データを逐一出力せずに一旦溜めておくこと。

拡張子が .in のファイル

  • .spec ファイルを生成するために、configure コマンドが利用するファイル。
  • configure が用いるファイルは、通常、元のファイルの拡張子に .in を追加するとのこと。

config/config.h.in

  • define がたくさん。定数の定義をしてます。

config/pathdef.c.in

  • これも define がたくさん。定数の定義をしてますが、ファイル名からして恐らくパスの設定をしているんだろう。

PHONY (Makefileに書いてあるやつ)

http://objectclub.jp/community/memorial/homepage3.nifty.com/masarl/article/gnu-make/rule.html

ターゲットとして,実際に存在しないファイル名を指定することができます.これは, 擬似ターゲットと呼んだり,ダミーターゲットと呼ばれたりしますが,統一された用語はないようです.そこで,ここでは便宜上タスクまたはタスクターゲットと呼ぶことにします(これと対比させるため,ファイルをファイルターゲットと呼ぶことにしましょう).タスクターゲットは,ある特定のファイルを作るためではなく,作業を行うコマンドとして利用したい場合に用いられます.

  • タスクの定義ってところでしょうか。

valgrind

http://www.ninxit.com/blog/2009/04/26/valgrind-%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%9F/

linux 環境で動く超強力なメモリデバッガー。メモリリークや、セグメンテーション違反を起こしている正確な位置を教えてくれる。

メモリデバッガーと呼ばれる類のツールのようです。

neovim.rb

  • たぶん Mac の homebrew でインストールするための設定と推測しました。

client.py

  • Python で書かれた何か。何をしているかはまだ分からない。

uncrustify.cfg

  • uncrustify は検索したところコードフォーマッター。見た目を整形するツール。そしてこのファイルはその config ファイル。

コンパイルされるまでの手順

  • make cmake これは、Makefile の cmake: clean deps で定義されていました。
cmake: clean deps
    mkdir build
    cd build && cmake $(CMAKE_FLAGS) $(CMAKE_EXTRA_FLAGS) ../
  1. build というディレクトリを作る。
  2. build ディレクトリに移動する。そして cmake コマンドを3つの引数を渡して実行する。

$(CMAKE_FLAGS) (CMAKE_EXTRA_FLAGS) ../ といった引数の意味を調べると、$() という記法は変数の展開であるから、どこかでCMAKE_FLAGSCMAKE_EXTRA_FLAGSが定義されているはず...。

CMAKE_FLAGS の定義場所

Makefile の 3 行目に書いてありました。

CMAKE_FLAGS := -DCMAKE_BUILD_TYPE=Debug -DCMAKE_PREFIX_PATH=.deps/usr -DLibUV_USE_STATIC=YES

cmake コマンド

  • make cmake を実行すると cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_PREFIX_PATH=.deps/usr -DLibUV_USE_STATIC=YES が実行されている。
  • cmake./configure を置き換えるものである。
  • なので cmake を実行すると Makefile が生成される。
  • CMakeLists.txtcmake を実行する時の設定ファイルである。

less のソースコードを読んでみたほうが良いかも

  • 理由は動きが vim と似てるから。less は書き込みができない vi のようなものというイメージがあるので。
  • とりあえず、less の動作は引数に渡されたファイルを読み出すのは知ってる。
  • なので、ファイルの内容を読みだして画面に表示させ続けるところとかユーザーからのキー入力で画面を操作するところとかどうやってるのかが分かるかもしれない。
  • neovim のソースコードを理解する一助になるかも。

(仮説)画面に描画する処理は恐らく screen.c

  • less のソースコードにも screen.c があった。
  • どっかのブログの記事で screen.c がうんたら書いてあったため。
  • neovim にもあった。
  • でもライセンス表記がない。つまりライブラリとして提供されているわけではなく、画面描画の処理は screen.c にするという慣習があるのかも。

続く