Software Engineering Lecture 7/18

Menu Menu

先週の復習

バージョン管理と構成管理

プログラムを始めとするさまざまな文書は必ず繰り返しの変更を受ける。それを版(Version)として管理するのがバージョン管理ツールである。

Unix では通常テキスト(プレーンテキストともいう)の処理が充実しており、文書の行毎の違いを抜き出すdiff、diffの違いを元に文書を修正するpatch、文書の保存を行うtar、圧縮を行うcompress などのツールがある。これらを組み合わせたツールとして、SCCS や RCS (Revision Control System) などのバージョン管理ツールが作られた。

プログラムやプロジェクトはソースコードやドキュメント、テストデータなどのさまざまな種類のファイルが含まれている。これらを特定のアプリケーションにより一括して管理することもできる。これらの機能は、Windowsなどでは統合プログラミング環境の一部として組み込まれている場合もある。

これらのファイルから最終的な実行形式を作ることはビルド(build) と呼ばれる。ビルドは多数のさまざまなファイルが係わる複雑なものである。ファイルの追加や削除などによって変わる複雑な作成方式の詳細や、プログラムの変更の際のビルドの最小限度の実行などの管理を構成管理と呼ぶ。構成管理はバージョン管理とは独立であり、Unixではビルドは Make と呼ばれるプログラムとMakefileによる記述で処理される。

diff, RCS, patch

diff -c とは何か?

RCS (revision control system) 

    ci -l filename
    co -r1.1 filename
    rcsdiff -r1.1 filename
patch program 

    patch < patch.file

問題

1から100までの数字をランダムに生成し、それをsort するプログラムを C で記述せよ。

最初の版を RCS に ci -l せよ。

コンパイラエラーをとった版を ci -l せよ。

実際に動くまでデバッグし、ci -l せよ。

rcsdiff で、どの程度間違いがあったかをチェックすること。

revisoin 1.1 と 最終版の patch file を作れ。

patch プログラムによって、revison 1.1 に正しくパッチがあたることを確認せよ。

バージョン管理とCVS

文書やソースは、順序良く変更されるとは限らない。一つの文書に複数の変更がほどこされる場合もあり、その場合は、同時に複数の独立した版が作成される。一般的に版は、木構造を持つ。版は数字で表現されることも多いが、3.14 などようにメジャー版番号3と、.14 などのマイナー版番号にわけることも多い。現実には、徐々にマイナー版番号が深くなることが多く、なかなかメジャー版番号は進まない。例えば、GNUコンパイラの版番号は2.7.2.1などのように細かくなっている。TeX では最終版として固定される版はπ(3.1415...)などになる予定とされている。

Unixでの標準的なバージョン管理ツールはRCSを発展させたCVS(Concurrent Versions System)である。CVSの基本的なコマンドは以下のようなものがある。 

       cvs checkout modules    モジュールの取り出し
       cvs update              最新版と私的版の融合
       cvs add file            ファイルの追加
       cvs remove file         ファイルの削除
       cvs commit file         変更の公開
CVSは、まず私的版(Private Version)を作り、それを最新版に維持しながら変更を完成させ、それを共有された版(Repository) に反映させるという手順を取る。

インターネット上でのプログラム開発では、各地に分散している開発者がCVS ツリーと呼ばれるCVSをサーバとして構成した版管理を採用することが多い。ロックを最小限にとどめるように考慮されたCVSは、このような用途に向いている。

CVSでは、基本的な版管理はRCSを用いており、RCSはdiffを使って変更の履歴を管理している。最新版と変更版の融合(Merge)は、diffを元に変更の衝突を解決しながら修正していく操作となる。

構成管理ツール Make

Make は、ソースなどの依存関係を調べながら、コンパイルやコード生成などを行っていくツールである。依存関係は、例えば、Makefile というファイルに 
	test1 : test1.o  test2.o
		cc -o test1 test1.o test2.o
	test1.o :  test1.c test.h
の用に記述される。これは、test1 がオブジェクトファイルtest1.oとtest2.o からCコンパイラccによって作られ、test1.o は、さらに test1.c と、それが参照するtest.h を見るという意味である。Make には、さらに基本的なルール、例えば、.o ファイルは .c ファイルから cc を使って作るというルール 
	.c.o : 
		cc -c $> -o $<
が含まれている。Makeの機能は、このようなルールを解決し、ルールに付属するコマンドを実行していくことである。実際には、さらに複雑な変数置換や制御文などが含まれていることもある。

ビルドの依存関係はプログラム言語によって決まるので、自動的な抽出を行うことも可能である。makedepend などのツールがMakefileを生成する形で使われることが多い。

コンフィグレーション

Make は特定の環境下でのプログラムの構成方法を解決するものだが、プログラムはWindows と Unix のような複数の環境をターゲットとすることも多い。統合環境は、環境への依存度が高く複数プラットホームのプログラムには比較的非力である。この場合は、構成方法自体も環境によって異なることになる。これはMakeを実行する以前に解決すべき問題でありコンフィグレーション(Configuration)と呼ばれる。さらに、多環境でのコンフィグレーションを作成するメタコンフィグレーションという概念も存在する。

コンフィグレーションを自動的に行うには、環境間のなんらかの共通ツールが必要である。Unix ならばシェルを使うことができるが、Windows や Mac OS では、そのようなものを基本的に欠いているので、なんらかのツールをまず導入する必要がある場合が多い。Unix を前提としたX-Window システムでは、独自にimake と呼ばれるコンフィグレーションツールを導入して、Imakefile から Makefile を生成するということが行われている。その他の多くのUnixツールでは、configure というシェルスクリプトが、自動的に多くのUnixの違い(ヘッダファイルの位置や、ライブラリの互換性、バイナリフォーマットの違いなど) を検出し、ヘッダファイルやMakefileを生成するようになっている。configure 自体はmetaconfigというツールから生成されることもある。 

    automake について調べてみよう

Perl のモジュール

Perlの場合は、Perlが導入された時に使われたコンフィグレーションを保持し、Perlのモジュールの導入の際には、Perlスクリプトを使って、そのコンフィグレーションを参照しながらビルドをおこなうようになっている。 

    Perl module の作り方について調べよう

Unix Kernel の Build

config ツール

file ユーティリティ

option の扱い

X-Window の Build

Imakefile

Imake.rule

Unix のパッケージ

rpm

ports

Interface Builder

統合プログラミング環境

宿題

この授業で出て来た、さまざまな build 方式について、一つを選びその欠点と利点を考察せよ。

情報工学科全体を管理するCVSを導入することについて、実現方法を示し、その利点と欠点を示せ。

解答は、kono@ie.u-ryukyu.ac.jp まで、来週までにメールで送ること。Subject には、 

   Report on Software Engineering Lecture 7/11
を付けること。

Shinji KONO / Tue Jul 11 14:54:41 2000