R の拡張を書く
Version 2.15.2
R Core Team

Permission is granted to make and distribute verbatim copies of this manual provided the
copyright notice and this permission notice are preserved on all copies.
Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed
under the terms of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice
may be stated in a translation approved by the R Core Team.
c
Copyright ⃝ 1999–2012 R Core Team
ISBN 3-900051-11-9
日本語訳注 このドキュメントの日本語訳は、
：
英語原文と全く同じ条件の下で自由に配布、
利用、
修正可能である。R の開発の早さから、こうした文章の日本語訳は常に"旧式化"していること
をお断りしておく。翻訳の妥当さについては保証しない。これらの理由から、R の最新バージョ
ンに付属する文章を適宜参照していただきたい。なお、本ドキュメントは Twitter ID:@ito yan
が作成した。

i
Table of Contents
謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1
R のパッケージを作る . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
パッケージの構造 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 DESCRIPTIONファイル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 INDEXファイル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.1.3 パッケージのサブディレクトリ . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1.4 パッケージバンドル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1.5 パッケージ中のデータ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1.6 パッケージ中の非 R スクリプト . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 コンフィギュアとクリーンアップ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2.1 Makevarsを使う . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2.1.1 OpenMP のサポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.2.1.2 pthreads を使う . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.2.1.3 サブディレクトリでのコンパイル . . . . . . . . . . . . . . . . . . . . 25
1.2.2 コンフィギュアの例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.2.3 F95 のコードを使う . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.3 パッケージのチェ
ックとビルド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.3.1 パッケージのチェ
ック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.3.2 パッケージの tar 書庫をビルドする . . . . . . . . . . . . . . . . . . . . . . . . 32
1.3.3 バイナリパッケージをビルドする . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.4 パッケージのビニェ
ットを書く . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.4.1 エンコーディングとビニェ
ット . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.5 CRANにパッケージを提出する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
1.5.1 PDF のサイズ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
1.5.2 パッケージの計時 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1.5.3 Windows の外部ソフトウェア . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1.6 パッケージの名前空間 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1.6.1 インポートとエクスポートの指定 . . . . . . . . . . . . . . . . . . . . . . . . . 42
1.6.2 S3 メソッドの登録 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
1.6.3 ロードフック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
1.6.4 useDynLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
1.6.5 例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
1.6.6 要約 – 既存のパッケージの変換 . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
1.6.7 S4 クラスとメソッドの名前空間 . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
1.7 移植可能なパッケージを書く . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
1.7.1 エンコーディングの問題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
1.7.2 バイナリの配布 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
1.8 診断メッセージ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
1.9 国際化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
1.9.1 C レベルのメッセージ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
1.9.2 R のメッセージ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
1.9.3 翻訳の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
1.1

ii
1.9.4 Makefile のサポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10 CITATION ファイル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.11 パッケージタイプ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.11.1 フロントエンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.12 サービス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
R のドキュメントを書く . . . . . . . . . . . . . . . . . . . . . . . . . 58
Rd 書式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 関数のドキュメント化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 データセットのドキュメント化 . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3 S4 クラスとメソッドのドキュメント化 . . . . . . . . . . . . . . . . . . . .
2.1.4 パッケージのドキュメント化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 セクショニング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 テキストを目立たせる . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 リストと表 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5 相互参照 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6 数学 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.7 図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.8 挿入 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.9 索引 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.10 プラットフォーム固有の文書 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.11 条件付きテキスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.12 動的なページ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.13 ユーザ定義のマクロ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.14 エンコーディング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.15 Rd 書式の処理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.16 Rd ファイルの編集 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1
3
55
56
57
57
57
58
59
64
65
66
66
67
68
69
70
71
71
72
72
73
73
74
75
76
76
R コードの整理とプロファイリング . . . . . . . . . . . . . . 77
R コードの整理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
速度のために R コードを整理する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
メモリ使用量のために R コードを整理する . . . . . . . . . . . . . . . . . . . . .
3.3.1 Rprofのメモリ統計値 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2 メモリ割り当ての追跡 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.3 オブジェクトのコピーの追跡 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 コンパイル済みコードの整理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1.1 sprof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1.2 oprofile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.2 Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.3 Mac OS X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1
3.2
3.3
77
77
79
80
80
80
81
81
81
82
83
83

iii
4
デバッグ作業 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.1 ブラウジング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 R コードのデバッグ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 gctorture と valgrind を使う . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 gctorture を使う . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.2 valgrind を使う . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4 コンパイル済みコードのデバッグ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.1 動的にロードされたコードでエントリポイントを見つける . .
4.4.2 デバッグ中に R オブジェクトを検査する . . . . . . . . . . . . . . . . . .
5
84
85
89
89
90
92
93
94
システムと他言語間のインタフェース . . . . . . . . . . . . 96
オペレーティングシステムへのアクセス . . . . . . . . . . . . . . . . . . . . . . . . 96
インタフェース関数.Cと.Fortran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
dyn.loadと dyn.unload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
ネイティブルーチンの登録 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.4.1 速度の考慮 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.4.2 他のパッケージ内のネイティブルーチンへのリンク . . . . . . . 103
5.5 共有オブジェクトの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.6 C++コードとのインタフェース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.7 Fortran I/O. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.8 他のパッケージへのリンク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.8.1 Unix 系 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.8.2 Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.9 C で R のオブジェクトを扱う . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.9.1 ガーベージコレクションの影響を扱う . . . . . . . . . . . . . . . . . . . . 111
5.9.2 ストレージの割り当て . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.9.3 R の型の詳細 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.9.4 属性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.9.5 クラス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
5.9.6 リストを扱う . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.9.7 文字データを扱う . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.9.8 変数の発見と設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
5.9.9 いくつかの便利な関数 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
5.9.9.1 半内部の便利な関数 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.9.10 名前付きオブジェクトとコピー . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.10 インタフェース関数.Callと.External . . . . . . . . . . . . . . . . . . . . . . 120
5.10.1 .Callの呼び出し . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
5.10.2 .Externalの呼び出し . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
5.10.3 欠損値と特殊値 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
5.11 C から R の式を評価する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.11.1 ゼロ点を見つける . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.11.2 数値微分の計算 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.12 C から R のコードを構文解析する . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
5.12.1 ソース参照へのアクセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
5.13 外部ポインタと弱参照 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
5.13.1 例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
5.14 ベクトルアクセサ関数 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
5.15 文字エンコーディングの問題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
5.1
5.2
5.3
5.4

iv
6
The R API: C コードのエントリポイント . . . . . . 136
メモリ割り当て . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.1 一時的な記憶領域の割り当て . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.2 ユーザに制御されたメモリ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 エラー処理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 FORTRAN からのエラー処理 . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 乱数生成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4 欠損値と IEEE特殊値 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5 印字 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.1 FORTRAN からの印字 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6 FORTRAN から C を呼ぶこととその逆 . . . . . . . . . . . . . . . . . . . . . . .
6.7 数値解析サブルーチン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.7.1 分布関数 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.7.2 数学関数 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.7.3 数値ユーティリティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.7.4 数学定数 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.8 最適化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.9 積分 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.10 ユーティリティ関数 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.11 再エンコーディング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.12 割り込み許可 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.13 プラットフォームとバージョン情報 . . . . . . . . . . . . . . . . . . . . . . . . . .
6.14 C 言語の関数のインライン化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.15 可視性の制御 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.16 自身の C コード内でこれらの関数を使う . . . . . . . . . . . . . . . . . . . . .
6.17 ヘッダファイルの構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1
7
総称的関数とメソッド . . . . . . . . . . . . . . . . . . . . . . . . . . 154
7.1
8
137
137
137
138
138
138
139
139
140
140
141
141
142
143
144
145
146
147
149
149
150
150
151
151
152
新しいジェネリクスを加える . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
GUI と他のフロントエンドを R と結びつける . . . 156
Unix 系で R を組み込む . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.1 R ライブラリに対するコンパイル . . . . . . . . . . . . . . . . . . . . . . . .
8.1.2 R のコールバックの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.3 シンボルの登録 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.4 イベントループのかみ合わせ . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.5 スレッドの問題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 Windows で R を組み込む . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.1 (D)COM を使う . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.2 直接 R.dll を呼び出す . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.3 R HOME を見つける . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1
156
158
158
161
162
163
163
163
164
167
関数と変数の索引 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
概念の索引 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

謝辞
1
謝辞
(.Call and .Externalの使い方に関する最初の草稿を書いた)Saikat DebRoy と (C++とのイ
ンタフェースに関する情報を提供してくれた)Adrian Trapletti の貢献に大いに感謝する。

Chapter 1: R のパッケージを作る
2
1 R のパッケージを作る
パッケージはオプションのコード、データ、ドキュメントを必要に応じてロードするメカニズ
ムを提供する。R 自身はおよそ 30 のパッケージを含んでいる。
以下では、lib.loc 引数を含め、library()について知っているものと仮定する。また、
R CMD INSTALLの効用について基本的な知識を持っているものと仮定する。もし知識を持って
いないようであれば、読み進める前に R の以下のヘルプのページを見ておくこと。
?library
?INSTALL
計算環境については、いくつかのツールを仮定する。“R Installation and Administration”
は何が必要であるかということについて記述している。Unix 系の大部分のツールについては
デフォルトで用意しているであろうが、Microsoft Windows は注意深いセットアップを求め
てくるかもしれない。
いったんソースパッケージが作られると、R CMD INSTALLというコマンドによってパッケー
ジはインストールされる。
他の拡張方法についてはサポートしない (ただし、稀である): See Section 1.11 [パッケー
ジタイプ], page 57 。
専門用語に関する注釈でこの導入を終える。これはマニュアルを読む手助けとなるであろ
う。また、助けを求めるときに、正確に概念を記述する際にも役立つであろう。
パッケージとは、R を拡張するファイルのディレクトリである。これはソースパッケージ
(パッケージのマスタファイル) か、ソースパッケージのファイルを含む tar 書庫、あるいは
ソースパッケージで R CMD INSTALLを走らせた結果インストールされたパッケージのいずれ
かを指す。いくつかのプラットフォームにおいては、ソースからインストールするというよ
りも、解凍可能なインストール済パッケージを含む zip ファイルあるいは tar 書庫を指すバイ
ナリパッケージといったものがある。
パッケージはライブラリではない 1 。ライブラリは R のドキュメントにおいては、2 つの
意味で使われている。1 つ目はパッケージがインストールされたディレクトリという意味であ
る。e.g. /usr/lib/R/library: その意味で、ディレクトリはライブラリディレクトリあるい
は ライブラリツリーとして言及される (ライブラリはそれ自身がディレクトリを持つ、パッ
ケージを含んだディレクトリであるため)。2 つ目の意味はオペレーティングシステムによっ
て共有ライブラリ、静的ライブラリ、あるいは (特に Windows 上の)2 つ目の L が ‘library’ を
略したものである DLL として使用されたというものである。インストールされたパッケージ
は、大部分の Unix 系の環境では共有オブジェクトとして知られるコンパイルされたコード、
Windows 上では DLL を含んでいる (かつては Unix 系の環境では共有ライブラリと呼ばれて
いた)。パッケージがリンクするコンパイルされたコードの集合である共有ライブラリ (Max
OS X 上では動的ライブラリ) のコンセプトは、あるプラットフォームにおける R 自身のため
に利用されている。
ソースパッケージについては、明確に定義された操作がたくさんある。もっともあ
り ふ れ たも のはイ ンス ト ー ルで 、ソー スパッケ ージを 受け 取り、R CMD INSTALLまた は
install.packagesを利用してパッケージをライブラリに組み込むということがある。異
なったコンセプトとしては、ソースパッケージはビルドできるということがある。これは、
ソースディレクトリにあるビニェットから PDF ドキュメントを作り出すといったことを含
1
しかし、これは一般的な誤用である。S に由来する、R パッケージと類似したものについて、正式にはライブ
ラリセクション、後にチャプターとして知られており、大体ライブラリとして言及されている

Chapter 1: R のパッケージを作る
3
め、ソースディレクトリを取り込み、いつでも配布できるような tar 書庫を作成することに
関与する。ソースパッケージ (ほとんどの場合 tar 書庫形式) はインストールテストがされた
ときと、(中に含まれる例を含め) テストされたときに、チェックされることがある。また、
パッケージの内容については、一貫性と移植性のため、さまざまな方法でテストされる。
コンパイルはパッケージに対しては、
正しい用語とはいえない。 や C++、
C
あるいは Fortran
のコードを含むようなソースパッケージをインストールすることは、コードをコンパイルす
るということに関与する。R 2.13.0 以降は、パッケージで R コードを (‘バイト’) コンパイル
できる可能性がある (コンパイラパッケージの機構を利用する): 将来的には、パッケージを
コンパイルするときに、これは定期的に行われる可能性があり、将来的にはパッケージの R
コードをコンパイルする意味になるかもしれない。
インストールされたパッケージを library()を利用してロードすることについて話題にす
ることについて、かつては曖昧さは無かったが、パッケージ名前空間の出現以来、はっきり
としなくなった: パッケージの名前空間をロードすること、それからパッケージをアタッチし
てサーチパス上でパッケージを見えるようにすることについて、今ではしばしば話をするよ
うになった。library関数は両方のステップについて機能するが、パッケージの名前空間につ
いては、パッケージがアタッチされることなくロードされる (例えば、splines::nsのような
呼び出しによる)。
コードやデータの遅延読み込みのオプションについては、何箇所かで触れられている。イ
ンストールの一部にあり、R コード (R2.14.0 以降) はいつでも選択されるが、データは任意
である。インストールの際にパッケージの R オブジェクトが作成され、インストールされた
‘R’
ディレクトリ中にあるデータベースに貯められ、セッションに初めてロードされるとき
にそのような仕組みが使われている。これによって、R セッションの実行速度が向上し、(仮
想) メモリの使用量が減る。
1.1 パッケージの構造
R パッケージのソースは、DESCRIPTIONファイルを含むサブディレクトリ、R、data、demo、
exec、inst、man、po、srcと testsを含むサブディレクトリ群から構成されている (いくつ
かはパッケージ中になくてもよいが、空であってはいけないものもある)。パッケージのサブ
ディレクトリは INDEX、NAMESPACE、configure、cleanup、LICENSE、LICENCEと NEWSも含
んでいるだろう。他の INSTALL (一般的なインストール手順ではないときのため)、READMEあ
るいは ChangeLogは R によって無視されるが、エンドユーザにとっては役立つかもしれない。
具体的に挙げられている場合を除き 2 、パッケージは Unix スタイルの ‘隠し’ ファイル/ディ
レクトリを含むべきではない (つまり、名前がドットで始まるもののことである)。
DESCRIPTIONと INDEXファイルは以下のサブセクションで説明されている。NAMESPACEファ
イルは、Section 1.6 [パッケージの名前空間], page 41 の項目で説明されている。
オプションファイルの configureと cleanupは (Bourne シェル) スクリプトであり、それ
ぞれ Unix 系の環境で、インストールの前と (--cleanというオプションが与えられたという条
件で) インストールの後で実行されるものである。Section 1.2 [コンフィギュアとクリーンアッ
プ], page 16 を見よ。Windows における同様のものは、configure.win and cleanup.winで
ある。
オプションファイル LICENSE/LICENCEはパッケージへのライセンスのコピーを含んでい
る。配布する source にライセンスファイルを含めるのは自由であると感じるはずであろう
が、一方で、GNU COPYINGあるいは COPYING.LIBファイルのもう一つのコピーを install する
2
現時点では、最上位層のファイル.Rbuildignoreと.Rinstignore、そして vignettes/.install_extras。

Chapter 1: R のパッケージを作る
4
準備は遠慮していだだき、http://www.r-project.org/Licenses/と R ディストリビュー
ション (share/licensesディレクトリ内部にある) に含まれたコピーについて言及してほし
い。LICENSE あるいは LICENCE という名前がついたファイルがインストールされることにな
るので、これらの名前を標準的なライセンスファイルの名前に用いてはならない。
GNUプロジェクトにおける、
NEWSと ChangeLogファイルに対する規則については、
http://
www.gnu.org/prep/standards/standards.html#Documentationを見よ。
パッケージのサブディレクトリについては、パッケージと同じ名前が与えられるべきであ
る。特定のファイルシステム (例えば Windows と Max OS の初期状態) においては大文字と
小文字を区別しないことから、移植性を維持するため、大文字と小文字の違いでパッケージ
を区別しないよう強く推奨する。例えば、fooと名前の付いたパッケージを持っているのであ
れば、Fooという名前のパッケージを作ってはならない。
ファイル名がファイルシステムと、サポートするオペレーティングシステムにおいて妥当
であることを確実にするために、ASCII制御文字は ‘"’、‘*’、‘:’、‘/’、‘<’、‘>’、‘?’、‘’と ‘|’と
同様にファイル名に用いることは認められていない。加えて、ファイル名で、小文字に変換し
て、あり得る拡張子を取り除いたときに、‘con’、‘prn’、‘aux’、‘clock$’、‘nul’、‘com1’から
‘com9’、‘lpt1’から ‘lpt9’を用いているものも拒否の対象となる (例えば ‘lpt5.foo.bar’)。ま
た、同じディレクトリのファイル名は大文字小文字が違うだけのファイル名があってはならない
(直前の段落を見よ)。さらに ‘.Rd’のファイル名は URL に使われるかもしれないので、ASCII
とし、%を含んではならない。移植性の最大化のため、ファイル名はすでに除外されていない
文字である ASCII文字だけを含むようにする (つまり、A-Za-z0-9._!#$%&+,;=@^(){}’[] —
多くのユーティリティではファイルパスの空白は受け入れられないので、空白は除外してい
る):英語に使われないアルファベット文字はすべてのロケールにおいてサポートされることは
保証されない。シェルのメタ文字 ((){}’[]$) を避けるのはよい習慣になるであろう。
可能であれば、ソースパッケージはバイナリ実行形式ファイルを含むべきではない:それ
らは移植性がなく、条件に適したアーキテクチャにおいては、セキュリティリスクになる。R
CMD checkはパッケージのトップレベルにある BinaryFilesというファイルの一覧 (1 行につ
き 1 つのファイルパス) にない限り、それらのファイル 3 について警告を行う。CRAN はリス
トにないものについて、バイナリファイルを含む提出を今後受け入れなくなることに注意。R
の package.skeletonという関数は、新しいパッケージを作成することに役立つ可能性があ
る。詳しくは関数のヘルプのページを参照せよ。
1.1.1 DESCRIPTIONファイル
DESCRIPTIONファイルはパッケージに関する基本的な情報について、以下のようなフォーマッ
トで含んでいる:
3
偽陽性はありうるが、これまでは少数である

Chapter 1: R のパッケージを作る
5
¨
Package: pkgname
Version: 0.5-1
Date: 2004-01-01
Title: My First Collection of Functions
Authors@R: c(person(Joe, Developer, role = c(aut, cre),
email = Joe.Developer@some.domain.net),
person(Pat, Developer, role = aut),
person(A., User, role = ctb,
email = A.User@whereever.net))
Author: Joe Developer and Pat Developer, with contributions from A. User
Maintainer: Joe Developer Joe.Developer@some.domain.net
Depends: R (= 1.8.0), nlme
Suggests: MASS
Description: A short (one paragraph) description of what
the package does and why it may be useful.
License: GPL (= 2)
URL: http://www.r-project.org, http://www.another.url
BugReports: http://pkgname.bugtracker.url
©
形式は ‘Debian Control File’ のそれである (‘read.dcf’のヘルプと http: / /www .debian .
org /doc /debian-policy /ch-controlfields .htmlを見よ: R は UTF-8 のエンコーディ
ングを要求しない)。継続行 (例えば、1 行よりも長い記述) は空白、あるいはタブから始ま
る。‘Package’, ‘Version’, ‘License’,‘Description’, ‘Title’, ‘Author’, and ‘Maintainer’の
フィールドは必須で、他のフィールドはすべて任意である。R 2.14.0 以降では、‘Author’ and
‘Maintainer’の項目は ‘Authors@R’から自動生成することができ、後者が提供されている場
合、前者は除去するべきである (それとパッケージは R (= 2.14)に依存する。詳しくは以下
を見よ): しかしながら、それらが ASCII 文字でない場合、提供することを推奨する。
移植性の最大化のため、DESCRIPTIONファイルの全体は ASCIIで書かれるべきである —
もし、それが可能でなければ、‘Encoding’フィールドを含めなければならない (以下を見よ)。
必須の ‘Package’フィールドはパッケージ名を与える。フィールドには文字、数値とドッ
トのみを含み、少なくとも 2 文字以上であり、文字で始まり、かつドットで終わってはなら
ないようにするべきである。
必須の ‘Version’フィールドはパッケージのバージョンを与える。これは少なくとも 2 つ
(通常 3 つ) の非負の整数の列で、区切り文字が ‘.’ または ‘-’ である列である。標準形は以下
のような例に見られるもので、‘0.01’ あるいは ‘0.01.0’といったバージョンは ‘0.1-0’とし
て扱われる。
必須の ‘License’フィールドは標準化された書式によって、パッケージのライセンスにつ
いて明確に記述するべきである。選択肢は縦線によって示されている。個々の仕様は次のど
れかである。
• “標準的な” 短い仕様の一つ
GPL-2 GPL-3 LGPL-2 LGPL-2.1 LGPL-3 AGPL-3 Artistic-1.0 Artistic-2.0
http://www.r-project.org/Licenses/ を介して利用可能となっており、そして、R
ソースまたはホームディレクトリのサブディレクトリの share/licensesに含まれている。
• フリーあるいはオープンソースのソフトウェアの短縮された名前 (FOSS、例えば http://
en.wikipedia.org/wiki/FOSS) で R のソースあるいはホームディレクトリの中にある
share/licenses/license.dbというライセンスデータベースの中に含まれていることで
ライセンスしており、おそらくは (バージョン管理されたライセンスに対しては)‘(op v)’
という形式のバージョン制限が続いているもの。op は比較演算子の ‘’、‘=’、‘’、‘=’、
‘==’あるいは ‘!=’であり、バージョンを特定する v(‘.’によって非負の整数が区切られてい

Chapter 1: R のパッケージを作る
6
る文字列) はおそらく ‘,’によって結合されている (下の例を見よ)。バージョン管理され
たライセンスに対しては、名前に続くバージョンで特定すること、あるいは存在している
省略形とバージョンを ‘-’を結合することもできる。さらに、フリー (http://www.fsf.
org/licenses/license-list.htmlを見よ) あるいはオープンソフトウェア (http://
www.opensource.org/licenses/bsd-license.phpを見よ) は必要があれば、データ
ベースに追加されることもある。
• ‘file LICENSE’あるいは ‘file LICENCE’という文字列の 1 つで、パッケージ (ソースある
いはインストール) のトップレベルにある LICENSEあるいは LICENCEと名づけられたファ
イルについてのことについて触れたもの。
• 配布に関する制限がないこと、(著作権法を含め) 関連法規で課された制約以外に使用に
制限がないということを意味する ‘Unlimited’という文字列
もし、パッケージが基となる FOSS ライセンス (例えば、帰属条項を含む GPL-3 あるい
は AGPL-3 を使用しているとき) を拡張してライセンスしているのであれば、その拡張は
LICENSEファイル (あるいは LICENCE) に置かれるべきであり、‘+ file LICENSE’という文字
列 (あるいは ‘+ file LICENCE’のそれぞれに) を対応する個々のライセンスの仕様に沿って付
けられるべきである。
標準化された仕様の例は以下のものがある。
License: GPL-2
License: GPL (= 2) | BSD
License: LGPL (= 2.0, 3) | Mozilla Public License
License: GPL-2 | file LICENCE
License: Artistic-1.0 | AGPL-3 + file LICENSE
“Public domain” は法域によっては認知されていないものであることから、妥当なライセ
ンスでないということについては、特に注意していただきたい。
ライセンスに関する情報を含めることは重要である。さもなければ、パッケージのコピー
を他人が再配布することすら合法的にならないかもしれない。‘License’フィールドは著作権
情報に利用してはならない: 必要であれば、‘Copyright’フィールドを利用せよ。
選んだライセンスについては、パッケージの依存するもの (システム依存のものを含めて)
についてもカバーすることを確かにしてほしい: 特に重要なのは依存するようなものの使用
に関するすべての制限について、DESCRIPTIONファイルを読む人に明確にすることである。
必須の ‘Description’フィールドは、パッケージが何をするかという包括的な記述を与え
る。いくつかの (完全な) 文を使えるが、1 段落のみに限られる。
必須の ‘Title’フィールドは、パッケージについての短い記述である。いくつかのパッケー
ジ一覧には、65 文字でタイトルを切り捨てるものがある。文字は大文字にする必要があり、
マークアップを使用せず、継続行を持たず、ピリオドで終わってはならない。
必須の ‘Author’フィールドは、誰がパッケージを書いたかということを表している。人間
の読者を対象として意図されたプレーンテキストのフィールドであり、すべての自動的な処
理 (すべての貢献者一覧の E メールアドレスを抽出するなど: ‘Authors@R’を使うため) は対
象としていない。すべての重要な貢献者については含められているということに留意するこ
と: もし、srcディレクトリにある他の人の作成物に対する R ラッパーを書いた場合、単独の
作者にならない (そして恐らく主要な作者にすらならない)。
必須の ‘Maintainer’フィールドは、(バグレポートを送るためなどの理由で) 山括弧に囲ま
れた有効な (RFC 2822) 単名の名前からなる E メールアドレスを与える。ピリオドやコンマ
で終わってはならない。公開するパッケージには person のメールアドレスを載せるべきであ

Chapter 1: R のパッケージを作る
7
り、メーリングリストや、企業体のメールではない: 現在も、パッケージの寿命の後も有効な
メールアドレスであるようにせよ。
もし、適切な ‘Authors@R’フィールドが与えられていれば、‘Author’と ‘Maintainer’のフ
ィールドは省くこともできる (R 2.14.0 以降)。‘Authors@R’フィールドは、適切な R コードに
よって、(特にそれらの正確な役割を明確にする)“authors” パッケージの正確で、機械が読める
記述を与えるのに使われることがある。役割は作者全員に対する ‘aut’ (author)、パッケー
ジを維持する人に対する ‘cre’ (creator)、特に貢献した人に対する ‘ctb’ (contributor)
がある。さらなる情報については、?personを見よ。初期状態では、役割が何もないことが
仮定されていることに注意せよ。自動生成されたパッケージの引用情報は次の仕様を利用し
ている: R 2.14.0 かそれ以降では、‘Author’と ‘Maintainer’のフィールドは、ビルドやイン
ストールの際に必要であれば、R から自動生成される。
いくつかの任意のフィールドは logical values を取る。これらについては、‘yes’、‘true’、
‘no’あるいは ‘false’によって明確になる:大文字になった値も受理される。
‘Date’フィールドは、現在のパッケージのバージョンがリリースされた日を与える。ISO
8601 の標準に従った、yyyy-mm-dd という形式を利用することを強く推奨する。
‘Depends’フィールドは、そのパッケージが依存しているパッケージの名前をコンマ区切り
で一覧にしたものを与える。パッケージ名は丸括弧に書かれたコメントが任意に続いている
かもしれない。コメントは比較演算子、空白と有効なバージョン番号を含むべきである。ま
た、もしパッケージが特定の R のバージョンに依存しているというのであれば、‘R’という特
別なパッケージ名を用いることもできる — 例えば、もしパッケージが R 2.11.0 か、それ以降
でしか動かない場合、‘Depends’フィールドには ‘R (= 2.11.0)’を含める必要がある。また、
R-devel あるいは R-patched に対し、特定の SVN の版を要求することもできる。例えば、‘R
(= 2.14.0), R (= r56550)’は、(リリースされたバージョン 2.14.0 も含めて)2011 年 7 月
下旬の R-devel よりも後のバージョンを必要とする。libraryと R パッケージのチェ
ック機構
はこのフィールドを利用している: ゆえに、不適切な文法の利用や、必要とされる他のパッ
ケージに対するコメントである ‘Depends’フィールドの誤使用はエラーとなる。他の依存 (R
システムの外部) については、‘SystemRequirements’フィールドに一覧にされるべきで、場
合によっては、READMEファイルに詳しく説明されるかもしれない。R INSTALLという機構は、
インストールされようとしているパッケージに対し、使われている R のバージョンが十分最
近のものであるか、現在のパッケージの前に明示されたパッケージが加えられるか (バージョ
ン要件を確認した後) ということを、libraryが呼ばれたときと、インストールの間に遅延読
み込みを準備しているときにチェ
ックする。
パッケージ (あるいは ‘R’) は、‘Depends’に 1 度より多く現れることもあるが、2.7.0 以前
の R のバージョンにおいては、最初に出現したものしか使われない: 今ではほとんど見かけ
ることはないだろうが。
バージョンを特定することなく Rの依存関係を宣言することは意味が無いし、base につい
てもそうである: これは R パッケージと base はいつでも利用可能だからである。
‘Imports’フィールドは、名前空間がインポートされる (NAMESPACEファイルに明記されて
いる) が、アタッチされる必要がないパッケージを一覧にしている。‘::’と ‘:::’演算子によっ
てアクセスされた名前空間が一覧にされているはずで、そうでなければ、‘Suggests’あるい
は ‘Enhances’にある (下記参照)。理想的には、このフィールドが使われている標準的なパッ
ケージをすべて含んでおり、S4 を利用したパッケージを含んでいることが重要である (クラ
ス定義が変化しうることと、DESCRIPTIONファイルはそれが起こった際にどのパッケージを
再インストールするかということを決める際に利用されるため)。‘Depends’フィールドに示さ
れたパッケージは ‘Imports’フィールドにも示されるべきではない。バージョン要件は明記さ

Chapter 1: R のパッケージを作る
8
れることもあるが、名前空間がロードされたときにはチェ
ックされない (その一方で、R CMD
checkを用いればチェ
ックされる)。
‘Suggests’フィールドは ‘Depends’と同様の文法を利用し、必ずしも必要としないパッケー
ジを一覧にしている。ここでは例、テストあるいはビニェ
ット (see Section 1.4 [パッケージの
ビニェ
ットを書く], page 35) でのみ使われるパッケージを含め、関数の本体でロードされる
パッケージを含める。例えば、foo パッケージの例が、bar パッケージのデータセットを利用し
ていると仮定しよう。すなわち、すべての examples/tests/vignettes を実行させたいと思わな
い限り、bar に foo を使わさせることが必ずしも必要でない: bar を持つことは役に立つが、必
ずしも必要ではない。バージョン要件は明記されることがあり、R CMD checkによって使用さ
れる。examples/tests/vignettes を走らせたいと思っているある人が推奨されているパッケー
ジを利用できないかもしれない (利用しているプラットフォームでインストールをすることす
ら可能ではないかもしれない) ので、推奨されたパッケージの使用が if(require(pkgname))
によって条件付きにされているかということが役に立つということを明記しておく。
最後に ‘Enhances’フィールドは、手元のパッケージによって “enhanced” されたパッケー
ジを一覧にしている。例えば、それらのパッケージからクラスのためにメソッドを提供する
こと、あるいはそれらのパッケージからオブジェクトを扱う手段を提供することが挙げられ
る (パッケージは R 固有の日時時刻関数を好むのだけれども、パッケージは chron (http://
CRAN.R-project.org/package=chron) から日時時刻オブジェクトを扱えるので、いくつか
のパッケージには ‘Enhances: chron’というものがある。)。バージョン要件は明確にされるこ
ともあるが、現在では利用されていない。そのようなパッケージはパッケージをチェ
ックする
ようなことを要求されない: それらを使用する任意のテストはパッケージが存在していること
が条件となる。(テストで例えば他のパッケージのデータセットを使うのであれば、‘Suggests’
にそのことを含め、‘Enhances’に含めてはならない。)
ルールの概要は以下の通りである。
• パッケージの名前空間で、library(pkgname)を用いてパッケージをロードすることだけ
に必要とされるものは ‘Imports’フィールドに記入し、‘Depends’に記入してはならない。
• library(pkgname)を用いてパッケージをうまくロードするためにアタッチされる必要
があるパッケージは、‘Depends’フィールドのみに記載されていなければならない。
• パッケージに対し、R CMD checkをうまく走らせるのに必要 4 とされるすべてのパッ
ケージは ‘Depends’、‘Suggests’、あるいは ‘Imports’のどれかひとつに記載されていな
ければならない。条件付きで例やテストを実行する際に使われるパッケージ (例えば、
if(require(pkgname))を用いて) は ‘Suggests’あるいは ‘Enhances’に記載されるべき
である。(これにより、チェ
ックするものは完全なチェ
ックをするのに必要とされるすべ
てのパッケージがインストールされていることを確実にすることが可能になる。)
特に、例のためのデータやビニェ
ット “だけ” を提供する大きなパッケージは、無駄のないイ
ンストールを可能にするため、‘Depends’よりも ‘Suggests’に入れるべきである。
パッケージをロードするときに libraryによって ‘Depends’フィールドのバージョン依
存関係は利用され、install.packagesは、‘Imports’と (dependencies = TRUEの場合に
は)‘Suggests’フィールドのバージョンを確認する。
4
これは data(theirdata, package = somepkg)という呼び出しから得られるデータと同様に libraryと
requireに直接呼ばれるすべてのパッケージも含む: R CMD checkはこれらのすべてについて警告を発する。
しかし、発見できないようなわずかな利用がある: 例えば、もしパッケージ A がパッケージ B を利用し、パッ
ケージ B を示唆あるいは高めるようなパッケージ C を使うパッケージ B の機能を利用する場合、パッケージ
A のためにパッケージ C を ‘Suggests’の一覧に入れる必要がある。含められたファイルでの宣言されていな
い使用は報告されないし、‘Enhances’に記載されたパッケージの無条件の利用も報告されない。

Chapter 1: R のパッケージを作る
9
これらのフィールドに書かれる情報は完全、かつ正確であることがますます重要となって
きている: 例えばそれは更新されたパッケージにどのパッケージが依存しているかというこ
とや、どのパッケージを平行してインストールしても安全であるかという計算するために利
用される。
‘URL’フィールドは、コンマあるいは空白で区切られた URLの一覧を与える。例えば、作
者のホームページや、ソフトウェアに関する追加資料があるページが見つけられるようにす
るためのものである。これらの URLは CRANのパッケージ一覧では、機能するハイパーリン
クに変換される。
‘BugReports’フィールドは、パッケージに関するバグ報告を提出する 1 つだけからなる
URLを含めることがある。パッケージを維持する人に E メールを送る代わりに、この URLは
bug.reportsで利用される。
Base と推奨されたパッケージ (例えば、R のソース配布物に含まれているパッケージ、あ
るいは CRANから入手可能でかつ R のすべてのバイナリ配布物に含めることが推奨されてい
るパッケージ) は、‘Priority’というフィールドを持ち、‘base’ あるいは ‘recommended’のど
ちらかの値が入っている。このような優先度は他のパッケージで利用してはならない。
‘Collate’フィールドは、パッケージ中の R コードのファイルがインストールで処理され
るときの照合順序を制御する際に用いられる。初期設定では、‘C’ロケールに応じて照合が行
われる。もしフィールドに値が存在するのであれば、照合仕様は (OS 特有のサブディレクト
リの可能性も考慮に入れて、Section 1.1.3 [パッケージのサブディレクトリ], page 11 を参照
せよ) 空白文字で区切られた Rのサブディレクトリとの相対ファイルパスの一覧として、パッ
ケージ中のすべての R コードのファイルを一覧にしなければならない。空白や引用符を含
むパスは引用符で囲まれる必要がある。OS 特有の照合フィールド (‘Collate.unix’あるいは
‘Collate.windows’) が ‘Collate’に代わって用いられる。
‘LazyData’論理フィールドは、R データセットが遅延読み込みを使用するかどうかを制御
する。‘LazyLoad’フィールドは、2.14.0 以前のバージョンでは利用されていたが、今では無視
される。
‘KeepSource’論理フィールドは、パッケージのコードが keep.source = TRUEあるいは
FALSEのどちらで供給されるかということを制御する。: keep.source = TRUEが常に選択さ
れることを意図されたあるパッケージでは例外的に必要とされることもある。
‘ByteCompile’論理フィールドは、パッケージのコードがインストールの際にバイトコン
パイルされるかどうかを制御する。: 現在は初期設定ではしないようになっており、特にバイ
トコンパイルによって利益があることが知られているパッケージに対しては役に立つことが
あるだろう (バイトコンパイルは長時間かかる可能性があり、パッケージのインストール容量
を増やす可能性がある)。
‘ZipData’論理フィールドは、自動の Windows ビルドがデータディレクトリを圧縮するか
しないかを制御する: もしパッケージが圧縮されたデータのディレクトリと一緒に動作しな
いようであれば、‘no’を設定せよ。(他の値に設定することは非推奨であり、R 2.13.0 からは
利用されない: しかし、パッケージが R の早い時期のバージョンの元でインストール可能で
あれば、まだフィールドは必要であるだろう。)
‘BuildVignettes’論理フィールドは、R CMD checkがビニェ
ットをテストするのを防ぐの
ことと、ビニェ
ットを R CMD buildによって再ビルドすることを止めるために、false に設定
することがある。これは例えば、パッケージのソースの一部ではない PDF が大きな図を必要
とする場合など、例外的に使用されるべきである。
もし DESCRIPTIONのファイル全体が ASCIIで書かれていない場合、エンコーディングを特
定する ‘Encoding’フィールドを含めるべきである。これは DESCRIPTIONのファイル自身と、

Chapter 1: R のパッケージを作る
10
Rと NAMESPACEのファイルのエンコーディング、および.Rdファイルのエンコーディングの初
期設定として用いられる。R CMD checkを走らせるとき、例はそのエンコーディングであるこ
とを仮定しており、CITATIONファイルのエンコーディングに用いられる。latin1、latin2、
および UTF-8という名前のエンコーディングのみが、移植性のあるものとして知られている。
(実際に必要でない限り、エンコーディングを特定してはならない: そのようにすることでパッ
ケージの移植性が低くなってしまう。もしパッケージが特定のエンコーディングを持つので
あれば、そのエンコーディングを用いているロケールで R CMD buildなどを走らせるべきで
ある。)
‘OS_type’フィールドは、パッケージが意図されている OS を明記している。もしフィール
ドがあれば、それは unixあるいは windowsのどちらかにするべきであり、そのパッケージは
‘.Platform$OS.type’にその値を持つプラットフォームに限ってインストールされるという
ことを示唆している。
‘Type’フィールドは、パッケージの種類を明記している。: see Section 1.11 [パッケージタ
イプ], page 57.
Note: パッケージ管理ツールによって加えられるので、‘Built’フィールドあるい
は ‘Packaged’フィールドはあってはならない。
‘Classification/ACM’フィールド (the Association for Computing Machinery の the
Computing Classification System を用いることによる,http: / /www .acm .org /class /)、
‘Classification/JEL’フィールド (the Journal of Economic Literature Classification
System, http: / / www . aeaweb . org / journal / jel_class_system . html)、あるいは
‘Classification/MSC’フィールド (the Mathematics Subject Classification of the American
Mathematical Society, http://www.ams.org/msc/) を用いたパッケージの内容に対して、
主題の分類を追加することができる。主題の分類は、それぞれの分類コードに対してコンマ
で区切られたリストで与えられる。例えば、‘Classification/ACM: G.4, H.2.8, I.5.1’の
ようになる。
‘Language’フィールドはパッケージのドキュメントが英語でないときにそれを示すために用
いられることを最後に述べておく: これは、現在 RFC 5646(http://tools.ietf.org/html/
rfc5646, こちらも参照のこと http://en.wikipedia.org/wiki/IETF_language_tag) に
よって定義されているように、標準 (私的な利用でも、新しく決められた定義を適用除外され
たものでもない) の IETF 言語タグがコンマ区切りで一覧になったものである。すなわち、基
本的に言語下位タグは ISO 639-1(http://en.wikipedia.org/wiki/ISO_639-1) の 2 文字、
あるいは ISO 639-3(http://en.wikipedia.org/wiki/ISO_639-3) にあるような 3 文字の
言語コードを使用せよ。
1.1.2 INDEXファイル
任意のファイルである INDEXはパッケージに含まれる十分に興味を引かれるオブジェクトに
ついて、その名前と説明を書いたものである (print メソッドのような関数は普段は明示的に
呼ばれるものではないので、含められていない)。普通は、このファイルはなく、対応する情
報はソースをインストールする時に、ドキュメントのソースから (tools::Rdindex()を使っ
て) 自動的に生成される。
パッケージに関してカスタマイズされた情報は、INDEX ファイルを編集するというより
も、マニュアルの概要 (see Section 2.1.4 [パッケージのドキュメント化], page 66)、ビニェ
ッ
ト (see Section 1.4 [パッケージのビニェ
ットを書く], page 35) の両方、またはどちらか一方
に加えておくことが望ましい。

Chapter 1: R のパッケージを作る
11
1.1.3 パッケージのサブディレクトリ
Rサブディレクトリは R のコードのファイルのみを含んでいる。インストールされるコード
ファイルは ASCII(大文字あるいは小文字) の文字あるいは数字で始まらなければならず、.R、
.S、.q、.r、あるいは.sという拡張子を 1 つ持っている 5 ものでなければならない。.Rとい
う拡張子は他のソフトウェアでは利用されていないように見受けられることから、我々はこ
の拡張子を利用することを推奨する。source()を用いることで、ファイルの内容を読むこと
が可能で、R オブジェクトが割り当てることによって生成される。ファイル名と生成される
R オブジェクトとの間に何も関係がないことに注意。理想的には、R コードのファイルは R
オブジェクトを直接割り当てるだけで、requireや optionsといった副作用を伴う関数は例
外なく呼び出してはならない。もしオブジェクトを生成するのに計算が必要となるのであれ
ば、計算ではパッケージ中の ‘earlier’ というコード (‘Collate’フィールドを参照せよ) と、生
成されたオブジェクトが名前空間のインポート以外で ‘Depends’パッケージに挙げられたパッ
ケージに依存しないという条件で、‘Depends’パッケージの関数を加えて使うことができる。
2 つの例外が許可されている: もし R サブディレクトリが sysdata.rdaというファイル (R
オブジェクトの保存されたイメージ: tools::resaveRdaFilesによって提案された適切な圧
縮形式を利用してほしい) を含んでいる場合、これは 名前空間/パッケージ 環境に遅延読み
込みされることになる – これはシステムデータセットに対し、dataを介してユーザがアクセ
ス可能になることを意図していないことを意味している。また、‘.in’で終わるファイルは、
ディレクトリ R以下で、configureスクリプトに適切なファイルを生成することを可能にして
いる。
コードファイルでは、ASCII文字だけ (それとタブ、LF や CR などの改行といった制御文
字) が利用されるべきである。他の文字はコメントでは受け入れられるが、そうすると、コ
メントは例えば UTF-8 ロケールの環境では読めなくなるかもしれない。オブジェクト中の非
ASCII文字があると、通常 6 はパッケージのインストール時に失敗する。引用符で囲まれた文
字列はどんなバイトでも許されるが、非-ASCII 文字に対してuxxxxというエスケープ文字
が使われるべきである 7 。しかし、非 ASCII文字列はいくつかのロケールでは使えないかも知
れないし、正しく表示されないかもしれない。
パッケージ中のさまざまな R の関数は初期化と片付けのために使われる。See Section 1.6.3
8
[ロードフック], page 44。
manサブディレクトリは R documentation (Rd) 形式で書かれたパッケージ中のオブジェ
クトに対する文書ファイル (のみ) を含んでいる。文書のファイル名は、ASCII(小文字あるい
は大文字の) 文字あるいは数字から始まり、.Rd (初期設定) あるいは.rdという拡張子を持た
せなければならない。さらに、名前は ASCIIで ‘%’を含まないような、‘file://’という URL
5
6
7
8
.Sと.sの拡張子は本来は S(-PLUS) で書かれたコードに起因するが、一般にはアセンブラのコードに使われ
ているものである。かつては暫定的に QPE と呼ばれていた拡張子.qが使われていた。
‘C’ロケールで実装された OS では当てはまる: Windows の ‘C’ロケールの考えは WinAnsi 文字セットを利用
するというものである。
パッケージは R (= 2.10)に依存している必要がある
R のバージョン 2.14.0 以前では、名前空間のないパッケージでは.First.libと.Last.libという関数がこれ
らのタスクを処理していた。(現在の R のバージョンではすべてのパッケージが名前空間を持っている。) 古
いパッケージの変換に役立てるため、ここに古いパッケージがどのように扱われていたかを載せておく: 慣習
的にそれらの関数は zzz.Rと呼ばれるファイルの中にそのような関数を定義していた。もし、.First.libが
パッケージ中に定義されているのであれば、パッケージがロード、取り付けされた後に、libnameと pkgname
の引数を伴って呼ばれていた。一般的な用途はコンパイルされたコードをロードするため、.First.lib内部
にある library.dynamを呼び出すものであった: 他の用途には副作用を伴った関数呼び出しがあった。もし、
パッケージ内部に.Last.libがあれば、取り外される直前にそれが (インストールされたパッケージの完全パ
スを引数に取った上で) 呼ばれていた。

Chapter 1: R のパッケージを作る
12
において有効なものでなければならない 9 。さらなる情報については、See Chapter 2 [R の
ドキュメントを書く], page 58。パッケージ中のすべてのユーザレベルのオブジェクトは文書
化されるべきであるということに注意; もしパッケージ pkg が “内部的な” 利用のみのユーザ
レベルのオブジェクトを含んでいるのであれば、パッケージはそのようなオブジェクトのす
べての記載した pkg-internal.Rdというファイルを提供するべきであり、ユーザによって呼
ばれるものではないということを明確に述べるべきである。例えば例として、R ディストリ
ビューション中の grid パッケージのソースを見よ。大規模に内部オブジェクトを利用するパッ
ケージは、文書化する必要がない場合、それらの名前空間からオブジェクトを外部に出すべ
きではないということに注意 (see Section 1.6 [パッケージの名前空間], page 41)。
manに文書ファイルがないことで、インストールエラーが起きる可能性がある。
Rと manサブディレクトリは、unixや windowsといった、OS 特有のサブディレクトリを含
んでいることがある。
コンパイルされたコードのソースとヘッダは srcにあり、加えて、必要に応じて Makevars
あるいは Makefileというファイルが置かれている。R CMD INSTALLを用いてパッケージがイ
ンストールされたとき、makeはコンパイルを制御することと、R にロードするための共有オ
ブジェクトにリンクするために用いられる。これのために makeの変数とルールには初期値が
あり (R が設定され、R_HOME/etcR_ARCH/Makeconfに記録されるときに決定される)、それぞ
れ.c、.ccあるいは.cpp、.f、.f90または.f95、.mと.mmあるいは.Mという拡張子で関連付
けられた、C、C++、FORTLAN 77、FORTLAN 9x10 、Objective C と Objective C++11 に対
してサポートを提供している。ヘッダには.hという拡張子を使うことを推奨しており、C++12
と Fortran 9x のインクルードファイルにも利用を推奨している。(C++のファイルに対し、.C
の拡張子を使うことはもはやサポートされていない。)srcディレクトリにあるファイルは隠
すべきではなく (ドットで始まるファイル)、R のあるバージョンにおいては、隠しファイル
は無視される。
1 つのパッケージにすべてのこれらの言語を混ぜることは移植性がなく (そしてまったく
可能がない場合がある)、C++と Fortran 9x の両方を用いることに対してサポートはしていな
い。R 自身が C と FORTRAN 77 は一緒に利用し、C と C++を混ぜることをしているため、
幅広く成功しているということが分かっている。
もし書いているコードがプラットフォームに依存する必要があるならば、コードには C か
C++に使われるような特定の定義がある。すべての Windows ビルド (64bit のものでさえも)
においては ‘WIN32’が定義される: 64bit の Windows ビルドでは ‘WIN64’も定義され、Mac OS
X では、‘__APPLE__’と ‘__APPLE_CC__’が定義される。
初期設定のルールは src/Makevarsファイルにマクロ 13 を設定することで微調整を行うこ
とができる。このメカニズムはパッケージ固有の src/Makefileに対する必要性を取り除くの
ほど十分一般的なものでなければならない。もし、そのようなファイルを配布するのであれ
ば、すべての R のプラットフォームでそのファイルが全体的に十分に働くよう、かなりの注意
9
10
11
12
13
より厳密には、英語のアルファベットと数字、および ‘$ - _ . + ! ’ ( ) , ; = ’という記号を含めることが
できる。
Ratfor はサポートされていない。もし Ratfor のソースコードがあるならば、それを FORTLAN へと変換す
る必要がある。FORTRAN 77(我々は大文字で書く) が唯一、すべてのプラットフォームでサポートしてい
るものであるが、多くの場合 Fortran-95(我々はこれに対しタイトルケースを使う) もサポートしている。も
し、Ratfor ソースファイルを出したいという場合、srcサブディレクトリにコードを入れ、メインのサブディ
レクトリに置かないようにしていただきたい。
特定のプラットフォームに置いては一方、あるいはどちらもサポートされていないかもしれない。
いくらか人気がある.hppを使う方法は、移植性を保障できるものではない。
POSIX 用語では GNU make による ‘make variables’ と呼ばれている。

Chapter 1: R のパッケージを作る
13
深さが必要とされる。もし仮にそれが任意のターゲットを持つのであれば、‘all’と名づけられ
た適切な最初のターゲットと、makeを走らせたことによって生成されたすべてのファイルを取
り除く (おそらく空の)‘clean’というターゲットを持つはずである (‘R CMD INSTALL --clean’
と ‘R CMD INSTALL --preclean’によって使用される)。Windows 上ではプラットフォーム特
有のファイル名がある: src/Makevars.winは src/Makevarsに優先し、src/Makefile.win
を使われなければならない。makeプログラムには、make ファイルに改行を含む完全な最終行
を必要とさせるものがある。
共有オブジェクトを作ること以外の目的で srcディレクトリを利用するパッケージもわ
ずかだがある (例えば、実行ファイルを作成するため)。そのようなパッケージには (Unix 系
の環境だけ、あるいは Windows だけということを意図していない限り、)src/Makefileと
src/Makefile.winというファイルがある。
とりわけ特別な場合のパッケージでは、srcディレクトリ内の共有オブジェクト/DLL 以外
にバイナリファイルを作るものがある。そのようなファイルは、R CMD INSTALL --libs-only
が複数のアーキテクチャを結合するために利用されることと、それが共有オブジェクト/DLL
をコピーするだけであるということから、マルチアーキテクチャの設定ではインストールされ
ない。もしパッケージから他のバイナリ (例えば実行プログラム) をインストールしたいという
場合、パッケージは共有オブジェクト/DLL をコピーするかわりに、インストールの一部で動
作する src/install.libs.Rという srcのビルドディレクトリに R のスクリプトを提供するべ
きである。スクリプトは以下の変数を含む異なる R の環境で動作する: R_PACKAGE_NAME(パッ
ケージの名前)、R_PACKAGE_SOURCE(パッケージのソースディレクトリへのパス)、R_PACKAGE_
DIR(パッケージのインストール先ディレクトリへのパス)、R_ARCH(パスのアーキテクチャ依存
部分)、SHLIB_EXT(共有オブジェクトの拡張子)、そして WINDOWS(TRUEは Windows 上、FALSE
は他の場所)。デフォルトの動作に近いものは、以下の src/install.libs.Rファイルを利用
して複製することができる:
files - Sys.glob(paste(*, SHLIB_EXT, sep=’’))
libarch - if (nzchar(R_ARCH)) paste(’libs’, R_ARCH, sep=’’) else ’libs’
dest - file.path(R_PACKAGE_DIR, libarch)
dir.create(dest, recursive = TRUE, showWarnings = FALSE)
file.copy(files, dest, overwrite = TRUE)
dataサブディレクトリは、データファイルのためのものである: See Section 1.1.5 [パッ
ケージ中のデータ], page 15
demoサブディレクトリは、パッケージのいくつかの機能性について実演する R スクリプ
ト (demo()を利用して走らせる) のためのディレクトリである。デモは対話式のものであるか
もしれないし、自動的にチェ
ックされるものでもないので、もしテストしたいということで
あれば、その達成のために testsディレクトリ中のコードを使うようにせよ。スクリプトの
ファイル名は (大文字あるいは小文字の) 文字で始まり、.Rあるいは.rのどちらかの拡張子を
持たなければならない。もしそのようなファイルがあるのであれば、demoサブディレクトリ
には、各デモに対し 1 行で、名前と、空白によって区切られた説明を与える 00Indexファイ
ルがある (この索引ファイルは自動的に生成することができないことに注意)。デモには指定
されたエンコーディングはないため、ASCII ファイルにするべきである (see Section 1.7.1 [エ
ンコーディングの問題], page 51)。
instサブディレクトリの内容は、再帰的にインストールディレクトリへとコピーされる。
instのサブディレクトリは、R によって使用されるサブディレクトリ (現時点では R、data、
demo、
exec、
libs、 、
man help、
htmlと Meta、
そして初期のバージョンで利用していた latex、
R-ex) の妨げになってはならない。instのコピーが起こるのは、srcがビルドされた後なので、

Chapter 1: R のパッケージを作る
14
srcの Makefileはインストールされるファイルを生成することができる。R 2.12.2 以前では、
ファイルはパッケージソースの権限を伴って POSIX プラットフォームにインストールされて
おり、再帰が深くなりすぎないことを保証するために注意がとられていた: R CMD buildは適
切な調節を行う。インストールされたものからファイルを除外するために、ソースディレク
トリのトップレベルに.Rinstignoreという除外するパターンのリストを指定することができ
る。それらのパターンは Perl ライクな正規表現であり (正確な詳細については、R の regexp
のヘルプを参照すること)、ファイルとディレクトリのパスに対し、マッチさせる 14 ものを 1
行につき 1 つ書く。例えば、doc/.*[.]png$は inst/docにある、すべての PNG ファイルを
(小文字の) 拡張子に基づいて除外する。
INDEX、LICENSE/LICENCEと NEWSを除いて、パッケージのトップレベルにある情報ファイル
はインストールされないので、Windows と Mac OS X のコンパイルされたパッケージのユーザ
には情報ファイルは知られない (そして tar 書庫に R CMD INSTALLあるいは install.packages
を使う人には見られない)。そのため、エンドユーザに見てもらいたい情報ファイルは、inst
に含められるべきである。もし名前つきの例外が instで発生した場合は、instのバージョン
がインストールされたパッケージで見られるということに注意。
instに追加したいものの 1 つに、citation関数に利用される CITATIONがあるかもしれ
ない。
testsサブディレクトリは、R ディストリビューションに付属している固有のテストに似
た、追加的なパッケージ特有のテストコードのためのものである。テストコードは.Rファイ
ルから直接、あるいは.Rファイルに対応するファイルを生成するコードを含む.Rinファイル
のどちらかから提供することができる (例えば、パッケージ中のすべての関数オブジェクトを
集め、変わった変数を伴ってそれらを呼ぶことによる)。.Rファイルを実行した結果は.Rout
ファイルに書き込まれる。もし.Rout.saveファイル 15 に一致するものがあれば、.Routファ
イルと.Rout.saveファイルは、エラーを起こさず、違いを報告する形で比較される。tests
ディレクトリはチェ
ックする領域にコピーされ、コピーされたものを作業用ディレクトリと
し、library(pkg_name)によって検査があると分かっている間、パッケージのコピーがインス
トールされていることを確かにするために R_LIBSが設定された上でテストは動作する。パッ
ケージ特有のテストは乱数シードを設定していない、普通の R セッションで動作するので、
乱数を利用するテストが再現可能な結果を得ようとするのであればシードを設定する必要が
ある (そして乱数を設定することは、すべての場合において、テストが動作する際に偶然の失
敗を避けるために役に立つ)。
もし testsサブディレクトリが、pkg-Ex.Rout.saveというファイルを含んだ Examplesと
いうサブディレクトリを持つのであれば、後者がチェ
ックされるときに、例を実行した出力
ファイルと比較される。
execサブディレクトリはパッケージが必要とする付加的な実行できるスクリプトを含んで
いることがあり、典型的なものはシェル、Perl あるいは Tcl といったインタプリタ型のスクリ
プトである。この機構は現在はごくわずかなパッケージのみが利用しているのみであり、ま
だ実験的なものである。注意:execの以下にあるファイルのみ (ディレクトリではない) がイン
ストールされ (そしてドットで始まるファイル名は無視される)、それらはすべて POSIX プ
ラットフォームにおいて、実行ファイルとして示されている (‘umask’によってモードは 775に
調節されている)。これはいくつかのプラットフォーム (Mac OS X と Windows を含めて) が
14
15
Windows では大文字と小文字は区別しない。
そのようなファイルを生成する最善の方法は、R CMD checkが上手くいった動作の結果から.Routをコピーす
ることである。もし、それとは別に生成したいということであれば、--vanilla --slaveというオプション
と英語のメッセージを得るために LANGUAGE=enという環境変数を設定した上で R を走らせよ。

Chapter 1: R のパッケージを作る
15
複数のアーキテクチャが同じインストールされたパッケージディレクトリを利用することを
サポートしているということから、実行可能なプログラムに対して適していないかもしれな
いことにも注意。
poサブディレクトリは現地語化に関連するファイルのために利用される: see Section 1.9
[国際化], page 53。
1.1.4 パッケージバンドル
パッケージバンドルのサポートは R 2.11.0 で廃止された。
1.1.5 パッケージ中のデータ
dataサブディレクトリは遅延読み込み、あるいは data()を用いることで使用可能となるデー
タファイルのためのディレクトリである。(その選択は DESCRIPTIONファイル中の ‘LazyData’
フィールドによってされる: 初期設定ではそのようにしないことになっている。) これはパッ
ケージが必要とする他のデータファイルに対して利用するべきではなく、そのようなファイ
ルに対しては、inst/extdataディレクトリを使用することが慣習になってきている。
データファイルは、拡張子によって 3 つの種類のうちのどれであるかということが示され
る: プレーンな R のコード (.Rあるいは.r)、テーブル (.tab、.txt、あるいは.csvである。
ファイルフォーマットについては?dataを参照せよ。そして.csvは標準的な 16 CSV 形式ではな
いことに注意)、あるいは save()イメージ (.RDataあるいは.rda)。ファイルは隠される (ドッ
トで始まる名前を持つ) べきではない。データファイルはパッケージをロードする必要が無く
利用できるようにするために、R コードは “自給自足” であるべきで、パッケージから提供さ
れる追加の機能を利用するべきではない。
イメージ (拡張子は.RDataあるいは.rda) は、イメージを作成する際に使われたパッケー
ジの名前空間への参照が含まれていることがある。データファイルにそのような参照がない
ことが望ましく、どのような場合においても、Dependsと Importsのフィールドに記載され
たパッケージになければならならず、そうでなければ、パッケージはインストールできなく
なるかもしれない。そのような参照を調べるには、普通の R セッションにイメージをロード
し、loadedNamespaces()の出力を見よ。
もしデータファイルが大きく、かつ ‘LazyData’を用いていないのであれば、dataサブディ
レクトリに datalistファイルを与えることで、インストールの速度を上げることができる。
datalistファイルは data()が見つける 1 つのトピックにつき 1 行からなり、もし、data(foo)
が ‘foo’を提供しているのであれば ‘foo’という形式で、あるいは data(foo)が ‘bar’と ‘bah’
を提供しているのであれば、‘foo: bar bah’という形式で書く。R CMD buildは tools::add_
datalist関数を用いることによって、自動的に 1MB を超える datalistファイルを dataディ
レクトリに加える。
テーブル (.tab、.txt、あるいは.csv) は gzip、bzip2あるいは xzによって圧縮され、必要
に応じて.gz、.bz2あるいは.xzという拡張子を持つ。しかしながら、そのようなファイルは R
2.10.0 かそれ以降のみで使用することができ、そのため、パッケージはその DESCRIPTION
ファイルに、適切な ‘Depends’エントリを持たなければならない。
もしパッケージが配布される予定なのであれば、ユーザに対し大きなデータセットのリ
ソースへの影響を考えるようにせよ: 大きなデータセットは、パッケージをロードするのに
何秒もかかるようにする他にも、パッケージのダウンロードをとても遅くさせ、歓迎できな
いストレージ空間の量を使い尽くことができるようにしてしまう。大きなデータセットは、
16
e.g http://tools.ietf.org/html/rfc4180.

Chapter 1: R のパッケージを作る
16
save(, compress = TRUE)(デフォルト) によって準備された.rdaイメージとして配布するの
が通常は最善である: ASCII コードでセーブされたものを配布することに言い訳の余地はな
い。bzip2あるいは xzを用いて圧縮することは、通常はパッケージの tar 書庫とインストー
ルされたパッケージの両方の容量を減らし、場合のよっては 2 倍かそれ以上になる。しかし
ながら、そのような圧縮は R 2.10.0 以降でのみ利用可能であり、そのためパッケージはその
DESCRIPTION ファイルに、適切な ‘Depends’エントリを持たなければならない。
tools パッケージは、データイメージに役立つ 2 つの関数を持っている: checkRdaFilesは
イメージが保存された方法について報告し、resaveRdaFilesは特定のイメージに対し、最適
な種類を選択することを含めて、異なった種類で圧縮して再保存するであろう。
‘LazyData’を用いたいくつかのパッケージでは、インストールされた遅延読み込みデー
タベースでは gzip 以外の別の圧縮形式を用いることで恩恵があるだろう。これは R CMD
INSTALLに対して--data-compressオプションを付ける、あるいは DESCRIPTIONファイルの
‘LazyDataCompression’フィールドを使うことによって選択されるようになる。役立つ値は
bzip2、xz、初期設定の gzipである。どれが最善であるかを見つける唯一の方法は、それら
を全部試して pkgname/data/Rdata.rdbファイルのサイズを見ることである。
遅延読み込みはとても大きなデータセット (シリアライズされたときに 2 ギガバイトを超
えるもの) に対してはサポートしていない。
1.1.6 パッケージ中の非 R スクリプト
コンパイルされる必要があるコード (C, C++, FORTRAN, Fortran 95 . . . ) は srcディレクト
リに含められ、このドキュメントの中の他の場所でも議論されている。
execサブディレクトリはシェル (例えば arulesSequences (http: / / CRAN . R-project .
org
/
package=arulesSequences))、BUGS、Java、JavaScript、Matlab、Perl
(FEST (http: / / CRAN . R-project . org / package=FEST))、php (amap (http: / /
CRAN . R-project . org / package=amap))、Python あ る い は Tcl、R さ え 含 ん だ イ
ン タ プ リ タ の ス ク リ プ ト の た め に 利 用 さ れ る こ と が あ る 。し か し な が ら 、例 え ば
AMA/inst/java、WriteXLS/inst/Perl、Amelia/inst/tklibs、CGIwithR/inst/cgibin、NMF/inst/matlabそして emdbook/inst/BUGSのように、instディレクトリを利用す
ることがより一般的のように思われる。
もしパッケージがそれらのインタプリタの 1 つや拡張を必要とするのであれば、そのこと
はパッケージの DESCRIPTIONファイルの ‘SystemRequirements’フィールドで宣言されるべ
きである。Windows ユーザは、R の Windows インストーラに含められている Tcl の拡張で
ある ‘BWidget’と ‘Tktable’は拡張であり、宣言される必要があるということを知っているべ
きである。‘Tktable’は Mac OS X 用に CRAN で配布されている Tcl/Tk の一部に乗り込ん
でいるが、ユーザにはその使い方を教える必要がある:
addTclPath(’/usr/local/lib/Tktable2.9’)
tclRequire(’Tktable’)
Tcl 2.9
1.2 コンフィギュアとクリーンアップ
この節は Unix 系の環境に特化している: 後で R の Windows の移植版に関するコメントにつ
いて見よ。
もしパッケージがインストール前にいくつかシステムに依存した構成を必要とするので
あれば、パッケージの中に configureという、他の動作の前に R CMD INSTALLによって (ファ
イルがあれば) 実行される、実行可能な (Bourne シェル) スクリプトを含めることができる。

Chapter 1: R のパッケージを作る
17
Autoconf のメカニズムによって生成されたスクリプトもありうるが、自身で書かれたスクリ
プトであるかもしれない。パッケージがコンパイルあるいは利用されたときにエラーメッセー
ジを出すというよりも、インストール時にパッケージ中の対応するコードが利用可能でない
ような、非標準のライブラリがあるか検出するためにこれを利用せよ。要するに、Autoconf
の最大限の力は拡張パッケージに利用可能である (変数の置換、ライブラリの探索など)。
Unix 系の環境下に置いてのみ、実行可能な (Bourne シェル) スクリプト cleanupは、R CMD
INSTALLに--cleanオプションが与えられていた時と、ソースからビルドするパッケージを準
備しているときの R CMD buildによって最後に実行される。cleanupはパッケージソースツ
リーを綺麗にするために利用されることがある: 特に configureによて作成されたすべての
ファイルを取り除くはずである。
例として、(C または FORTRAN) ライブラリ fooによって提供されている機能を使いたい
ということを考えよう。Autoconf を利用することで、私たちはライブラリをチェ
ックし、変
数 HAVE_FOOが存在すれば TRUEという値を、そうでなければ FALSEを設定し、その値を出力
ファイルに代入する (HAVE_FOOという値を持つ入力ファイル中の ‘@HAVE_FOO@’というインス
タンスを置き換えることによる) コンフィギュアスクリプトを作成することができる。例え
ば、もし barという名前が付けられた関数がライブラリ fooに対してリンクすることに利用
可能になるのであれば (つまり-lfooを使う)、configure.acの中でこのように使える。
AC_CHECK_LIB(foo, fun, [HAVE_FOO=TRUE], [HAVE_FOO=FALSE])
AC_SUBST(HAVE_FOO)
......
AC_CONFIG_FILES([foo.R])
AC_OUTPUT
(Autoconf 2.50 以降であることを仮定する).
foo.R.in中の対応する R の関数の定義は次のようになる。
foo - function(x) {
if(!@HAVE_FOO@)
stop(Sorry, library ’foo’ is not available))
...
このファイルから、もし (目的の機能をもった) ライブラリ fooが見つからなかった場合、
configureは次に見られるような foo.Rという実際の R のソースファイルを生成する。
foo - function(x) {
if(!FALSE)
stop(Sorry, library ’foo’ is not available))
...
この場合、上の R のコードは関数を事実上、利用不可能にする。
また、利用可能な機能と失われた機能のそれぞれに対して、異なったファイルの断片を利
用することができるだろう。
configureテストでは、R あるいはパッケージをコンパイルしているときのように、同じ
C コンパイラとコンパイラフラグが使われていることを確実にすることが必要となるであろ
う。Unix 系の環境下では、configure.acの初期に以下の断片を加えることによってこれを
達成することができる。

Chapter 1: R のパッケージを作る
18
: ${R_HOME=‘R RHOME‘}
if test -z ${R_HOME}; then
echo could not determine R_HOME
exit 1
fi
CC=‘${R_HOME}/bin/R CMD config CC‘
CFLAGS=‘${R_HOME}/bin/R CMD config CFLAGS‘
CPPFLAGS=‘${R_HOME}/bin/R CMD config CPPFLAGS‘
(単に ‘R’よりもむしろ ‘${R_HOME}/bin/R’を使うことが R CMD INSTALLの一部としてスクリ
プトを走らせるときに正しいバージョンの R を使用するために必要であり、‘${R_HOME}’に続
く引用符は空白を含んでいるかもしれない。)
もし、コードが負荷チェ
ックを行う場合、次のものが必要になるであろう。
LDFLAGS=‘${R_HOME}/bin/R CMD config LDFLAGS‘
そして、C++で書かれたパッケージは C++コンパイラの詳細を得る必要があり、以下のコー
ドによって、現在の言語を C++に切り替える必要がある。
AC_LANG(C++)
たとえば C ヘッダーは C++プログラムに対して利用可能でなく、C++の名前修飾を避けるた
めに書かれていないということから、後者は特に重要である。
基本的な設定変数あるいはヘッダの値を得るため、それと R に対してリンクする際に必要
となるライブラリフラグの値を得るために R CMD configを利用することができる。詳しくは
R CMD config --helpを見よ。
公式な Autoconf Macro Archive からの ACX_BLASマクロを利用する外部の BLAS ライブ
ラリをチェ
ックするには、単に以下のようにすれば可能である。
F77=‘${R_HOME}/bin/R CMD config F77‘
AC_PROG_F77
FLIBS=‘${R_HOME}/bin/R CMD config FLIBS‘
ACX_BLAS([], AC_MSG_ERROR([could not find your BLAS library], 1))
R によって決定される FLIBSは、すべての R プラットフォームにおいて、FORTRAN 77
のコードが動くことを確実にするために利用されなければならないことに注意が要る。FLIBS
を上書きするであろう Autoconf マクロ AC_F77_LIBRARY_LDFLAGSを呼ぶことは利用しては
ならない (そして、そのため例えば ACX_BLASから除外されている。(実際、Autoconf の最近
のバージョンでは、すでに設定された FLIBSが FORTRAN リンカフラグのテストのために上
書きすることを認めている。また R の最近のバージョンは外部の BLAS と LAPACK ライブ
ラリを検出することができる。)
コンフィギュアスクリプトは Windows システムで利用されないということは念頭におくべ
きである。もしパッケージが一般に入手可能になるのであれば、非 Unix 系のプラットフォー
ムのユーザが手動で設定できるよう十分な情報を与えるか、そのプラットフォームで利用さ
れるような configure.winというスクリプトを提供するようにして欲しい。(必要に応じて
cleanup.winがある可能性がある。両方のスクリプトとも Bourne スタイルの shの最小バー
ジョンである ashによって実行されるシェルスクリプトであるべきである。)configure.win
が実行されるとき、R_HOME(ファイルの区切り文字として ‘/’を利用する) と R_ARCHが環境変
数に設定されるであろう。R_ARCHは 64-bit ビルド (その値は ‘/x64’がある) であるかどうか
を決めるため、そして DLL を正しい場所 (${R_HOME}/libs${R_ARCH}) へインストールする
ために利用せよ。R_ARCH_BINは binディレクトリ以下の正しい場所を見つけるために利用せ
よ。例えば、${R_HOME}/bin${R_ARCH_BIN}/Rscript.exeである。

Chapter 1: R のパッケージを作る
19
まれな状況においては、コンフィギュアとクリーンアップのスクリプトはパッケージが
インストールされた位置を知る必要がある。この例として、C コードを利用し、2 つの共有
オブジェクト/DLL を作成するパッケージがある。通常、R によって動的に読み込みされる
オブジェクトは 2 番目の依存オブジェクトに対してリンクされる。あるシステムでは、R に
よって動的に読み込まれるオブジェクトに、この依存オブジェクトの位置を加えることがで
きる。これは各ユーザが LD_LIBRARY_PATH(か同等な) 環境変数の値を設定する必要がなく、
2 番目のオブジェクトが自動的に参照されるということを意味している。別の例として、パッ
ケージが実行時に必要となるサポートファイルをインストールするとき、それらの位置はイ
ンストール時に R のデータ構造に代入されるということがある (これは Omegahat の SJava
パッケージ中の Java Archive ファイルで起こる)。最上位のライブラリディレクトリの名前
(つまり ‘-l’引数で指定可能である) とパッケージ自身のディレクトリ名は 2 つのシェル/環
境変数 R_LIBRARY_DIRと R_PACKAGE_DIRによってインストールスクリプトで利用可能にな
る。加えて、インストールされているパッケージ名 (例えば、‘survival’、あるいは ‘MASS’)
は環境変数 R_PACKAGE_NAMEから利用可能である。(現時点では、 R_PACKAGE_DIRの値は常に
${R_LIBRARY_DIR}/${R_PACKAGE_NAME}であるが、これはバージョン管理されたインストー
ルが許されていたときは当てはまらなかった。主な用途は外部のソフトウェアの DLL のイン
ストールパスのための configure.winスクリプト中である。)R_PACKAGE_DIRの値は空白や、
他のシェルに優しくない文字を含んでいるかもしれないので、makefile とコンフィギュアス
クリプトでは、その値は引用符で囲うべきである。
さらに難しい作業の 1 つがヘッダと外部ソフトウェアのライブラリに見られる。Unix 系の
(Max OS X ではない) 環境で、これをするためにますます利用可能になってきているツール
が pkg-configである。configureスクリプトはコマンド自身の存在に対してテストをする必
要があり (例えば Cairo (http://CRAN.R-project.org/package=Cairo) を見よ)、そしても
し存在しているのであれば、例えば以下のように、ソフトウェアがインストールされている
場合、適切なバージョンとコンパイル/リンクフラグからなっているか尋ねることができる。
$ pkg-config --exists ’QtCore = 4.0.0’
$ pkg-config --modversion QtCore
4.7.1
$ pkg-config --cflags QtCore
-DQT_SHARED -I/usr/include/QtCore
$ pkg-config --libs QtCore
-lQtCore
# check the status
pkg-config --libsはそのライブラリ (通常は動的ライブラリ) の既定のバージョンにリンク
するのに必要となる情報を提供し、もし静的ライブラリが利用されるのであれば pkg-config
--staticが必要となることに注意。
pkg-configに知られているソフトウェアの名前は期待しているものではないことがある
(例えば 2.22 なのに ‘gtk+-2.0’)。完全なリストを得るためには、以下のものを利用せよ。
pkg-config --list-all | sort
1.2.1 Makevarsを使う
Makevarsファイルを提供することによって、ときおり configureスクリプトを書くことを回
避することができることがある: また configureスクリプトのもっとも一般的な利用の 1 つ
に、Makevars.inから Makevarsを作成するということがある。
Makevarsファイルは makefile であり、R CMD SHLIB(srcディレクトリ中のコードをコンパ
イルするための R CMD INSTALLによって呼ばれる。) によって、いくつかの makefile の 1 つと