• 情報メディア工学・ガイダンス/2024
• Webページの生成とプログラム言語
• JavaScriptによるフロントエンドとPHPバックエンド入門
• PHPとデータベースによるバックエンドプログラミング
• unixにおけるファイルとユーザ管理
• バックエンドと所有権の設定
• Webプログラミングとセキュリティ
• ネットワークとセキュリティ
• リダイレクトとパイプ
• Unix演習で ./a.out の理由
• フィルタとプロセス管理
• プロセス管理とシェルスクリプト
• シェルスクリプトの演習
• ライブラリと分割コンパイル
• プログラムのバージョン管理とオープンソース

プログラムを複数人で開発する場合のバージョン管理と、オープンソースプログラムを使う場合の注意を説明する。

バージョン管理システム

プログラムを学校や自宅のパソコンで開発する場合、そのソースコードはどのように持ち運び管理修正すべきだろうか？

最も原始的な方法は、常に全部を持ち歩く方法かもしれない。しかし、プログラムが巨大になってくるとコピーに時間がかかる。またコピーを取る時に、どれが最新なのか正しく把握する必要がある。

• 同期方式 – 2つのディレクトリのファイルの古い日付のファイルを、新しい日付のファイルで上書きするようなディレクトリ同期ソフトを使って管理
• 圧縮保管 – ファイル全体だと容量も多いため、複数のファイルを1つのファイルにまとめて圧縮を行う tar コマンドを使うことも多い。(tar ball管理)

diffとpatch

プログラムの修正を記録し、必要最小限で修正箇所の情報を共有する方式に patch がある。これには、2つのファイルの差異を表示する diff コマンドの出力結果(通称patch)を用る。diff コマンドでは、変更のある場所の前後数行の差異を !(入替) +(追加) -(削除) の目印をつけて出力する。patch コマンドに diff の出力を与えると、!,+,- の情報を元に修正を加えることができる。(通称「patchをあてる」)

((( helloworld-old.c )))
  #include <stdio.h>

  void main() {
        printf( "Hello World\n" ) ;
  }
 
((( helloworld.c )))
  #include <stdio.h>

  int main( void ) {
        printf( "Hello World\n" ) ;
        return 0 ;
  }
 
((( diff の実行 )))
$ diff -c helloworld-old.c helloworld.c
 
((( 生成された patch 情報 )))
*** helloworld-old.c    2022-07-25 10:09:10.694442400 +0900
--- helloworld.c        2022-07-25 10:09:26.136433100 +0900
***************
*** 1,5 ****
  #include <stdio.h>

! void main() {
        printf( "Hello World\n" ) ;
  }
--- 1,6 ----
  #include <stdio.h>

! int main( void ) {
        printf( "Hello World\n" ) ;
+       return 0 ;
  }

インターネットの初期の頃には、他の人のプログラムに対して間違いを見つけると、作者に対してこのpatch(diff出力)をメールなどで送付し、プログラムの修正が行われた。

広く世界で使われている Web サーバ apache は、オープンソースで開発されてきた。当初はプログラム公開後に間違いや機能追加の情報(patch)が世界中のボランティア開発者から送られてきながら改良が加えられていった。このため、”a too many patches”「つぎはぎだらけ」という自虐的皮肉を込めて apache と名付けられたと言われている。

初期のバージョン管理システム

バージョン管理システムは、複数人で少しづつテキストファイルに修正を加えながら改良を行うような際に、誰がどのような修正を行ったかという修正履歴を管理するためのツール。unix などのプログラム管理では rcs (revision control system) が使われていたが、その改良版として cvs (concurrent version system) が使われるようになっていった。(現在は後に紹介する Git などが主流)

• ci コマンド(check in) – ファイルをバージョン管理の対象として登録する。
• co コマンド(check out) – ファイルを編集対象とする(必要に応じて書き込みロックなども可能)。co されたファイルは、編集した人が ci して戻すまで ci することができない。
• 修正結果を ci する際には、新しい編集のバージョン番号などをつけて保存される。
• co コマンドでは、バージョン番号を指定してファイルを取り出すことも可能。

　　　　　　　　　　　　　　 　　[Bさんの修正]
　　　　　　　　　　　　　　 　／check out　＼check in
ファイルver1.0－－－－－→ver1.1－－－－－－→ver1.2
　　　　　＼check out　　／check in
　　　　　　[Aさんの修正]

集中管理型バージョン管理システム

rcs,cvs では、ファイルのバージョンは各ファイルを対象としているため、ファイルやディレクトリの移動や削除は管理が困難であった。これらの問題を解決するために、集中管理を行うサーバを基点として、対象ファイルのディレクトリ全体(ソースツリー)に対してバージョン番号を振って管理を行う。subversion はサーバに ssh などのネットワークコマンドを介して、保存・改変を行うことができる。

しかし、複数の人の修正のマージ作業の処理効率が悪く、処理速度が遅いため使われなくなっていった。同様のバージョン管理システムが企業により有償開発されていた(BitKeeperなど)が製品のライセンス問題が発生し、業を煮やした Linux 開発の Linus が Git のベースを開発・公開している。

分散型バージョン管理システム

Gitは、プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システムである。Linus によって開発され、ほかの多くのプロジェクトで採用されている。(以下wikipedia記事を抜粋加筆)

Gitは分散型のソースコード管理システムであるため、リモートサーバ等にある中心リポジトリの完全なコピーを手元（ローカル環境）に作成して、そのローカルリポジトリを使って作業を行う。

一般的な開発スタイルでは、大雑把に言えば、以下のようなステップの繰り返しで作業が行なわれる：

1. git clone – リモートサーバ等にある中心リポジトリをローカルに複製する。
2. git commit – ローカルでコンテンツの修正・追加・削除を行い、ローカルリポジトリに変更履歴を記録する。
   • 必要に応じて過去の状態の閲覧や復元などを行う。場合によってはこのステップを何度か繰り返す。
3. git push – ローカルの変更内容を中心リポジトリに反映させる。
4. git merge – git push の段階で、作業者ごとの変更内容が衝突することもある。Gitが自動で解決できる場合もあれば、手動での解決する。
5. git pull – 更新された中心リポジトリ（他者の作業内容も統合されている）をローカルの複製にも反映する。これによりローカル環境のコードも最新の内容になるので、改めてステップ2の作業を行う。

　　ローカルリポジトリ(Aさん)
　　　　　　　　　　　ver1.0a1　　　　　　ver1.0a2　　　　　　　　　　ver1.1a1
　　　　　　　修正--(git commit)--修正--(git commit)　　　　　　修正--(git commit)
　　　　　　／git clone　　　　　　　　　　　　　　＼git push ／git pull　Bさんの修正
中心リポジトリver1.0－－－－－－－－－－－－－－－－－ver1.1　　　　　　　も含まれる
　　　　　　＼git clone　　　　　　　　　　　　　　／git push
　　　　　　　修正--(git commit)--修正--(git commit)　　　編集の衝突が発生すると 
　　　　　　　　　　　ver1.0b1　　　　　　ver1.0b2　　　　　git merge が必要かも
　　ローカルリポジトリ(Bさん)

GitHub

Git での中心リポジトリを保存・管理(ホスティング)するためのソフトウェア開発のプラットフォーム。コードの管理には Git を利用し GitHub 社によって保守されている。2018年よりマイクロソフトの傘下企業となっている。

GitHub では単なるホスティングだけでなく、プルリクエストやWiki機能(ドキュメントの編集・閲覧機能)といった、開発をスムーズに行うための機能も豊富である。(個人的な例:github.com/tohrusaitoh/)

GitHub で管理されているリポジトリには、公開リポジトリと非公開リポジトリがあり、非公開リポジトリはその管理者からの招待をうけないとリポジトリ改変に参加できない。

企業でのプログラム開発で GitHub を内々で使っている事例なども多いが、間違って公開リポジトリと設定されていて企業の開発中のプログラムが漏洩してしまった…との事例もあるので、企業での利用では注意が必要。

オープンソースとライセンス

オープンソースプログラムは、プログラムのソースコードをインターネットで公開されたものである。しかし、元となったプログラムの開発者がその利用に対していくつかの制約を決めていることが多い。これらのオープンソースプログラムでのソフトウェア開発手法の概念として「伽藍とバザール」を紹介する。

伽藍とバザール

伽藍(がらん)とは、優美で壮大な寺院のことであり、その設計・開発は、優れた設計・優れた技術者により作られた完璧な実装を意味している。バザールは有象無象の人の集まりの中で作られていくものを意味している。

たとえば、伽藍方式の代表格である Microsoft の製品は、優秀なプロダクトだが、中身の設計情報などを普通の人は見ることはできない。このため潜在的なバグが見つかりにくいと言われている。

これに対しバザール方式では明確な方針が決められないまま、インターネットで公開されているプログラムをボランティアを中心とした開発者を中心に開発していく手法である。

代表格の Linux は、インターネット上にソースコードが公開され、誰もがソースコードに触れプログラムを改良してもいい(オープンソース)。その中で、新しい便利な機能を追加しインターネットに公開されれば、良いコードは生き残り、悪いコードは自然淘汰されていく。このオープンソースを支えているツールとしては、前に述べた git が有名。

オープンソース・ライセンス

ソースコードを公開している開発者の多くは、ソフトウェア開発が公開することで発展することを期待する一方で、乱用をふせぐために何らかの制約をつけていることが多い。最初の頃は、開発者に敬意を示す意味で、プログラムのソースコードに開発者の名前を残すこと、プログラムを起動した時に開発者の名前が参照できること…といった条件の場合もあったが、最近ではソフトウェアが広く普及・発展することを願って条件をつけることも多い。

こういったオープンライセンスの元となったのは、Emacs(エディタ),gcc(コンパイラ)の開発者のストールマンであり、「ユーザーが自由にソフトウェアを実行し、（コピーや配布により）共有し、研究し、そして修正するための権利に基づいたソフトウェアを開発し提供することにより、ユーザーにそのような自由な権利を与えた上でコンピュータやコンピューティングデバイスの制御をユーザーに与えること」を目標に掲げた GNU プロジェクトがある。linux を触る際のコマンドで、g で始まるプログラムの多くは GNU プロジェクトのソフトウェア。

GNU プロジェクトが掲げる GNU ライセンス(GPL)では、GPLが適用されていれば、改良したソフトウェアはインターネットに公開する義務を引き継ぐ。オープンソースライセンスとして公開の義務の範囲の違いにより、BSD ライセンス、Apacheライセンスなどがある。

GPLライセンス違反

GPLライセンスのソフトウェアを組み込んで製品を開発した場合に、ソースコード開示を行わないとGPL違反となる。大企業でこういったGPL違反が発生すると、大きな風評被害による損害をもたらす場合がある。

• SwitchBot 社製品のGPL違反の注意喚起 – といっても2年間放置されてたの?
• SwitchBot 社が、この2023年7月に、GPL違反の注意喚起を受け、ようやく対応したようだ

最近のライセンスが関連する話題を１つ紹介：GitHub を使った AI プログラミング機能「Copilot」というサービスが提供されている。Copilot のプラグインをインストールした vscode(エディタ) では、編集している関数名や変数名などの情報と GitHub で公開されているプログラムの 学習結果を使って、関数名を数文字タイプするだけで関数名・引数・処理内容などの候補を表示してくれる。しかし、Copilot を使うと非オープンライセンスで開発していたプログラムに、オープンソースのプログラムが紛れ込む可能性があり、非オープンソースプロジェクトが GPL で訴えられる可能性を心配し「Copilot は使うべきでない」という意見の開発者も出ている。Copilot だけでなく、生成系 AI によるプログラムでも、同様の問題が指摘されている。

理解度確認

• 理解度確認Forms

巨大なプログラムを作ってくると、プログラムのコンパイルに時間がかかる。こういった場合には、共有できる処理であればライブラリにまとめたり、分割コンパイルといった方法をとる。

C言語とライブラリ

C言語でプログラムを作っている時、printf() や scanf() といった関数を使うが、こういった組み込み関数のプログラムはどこに書かれているのだろうか？

ソースプログラムがコンパイルする際には、コンパイラ(compiler)によるコンパイル処理(compiler)、リンカ(linker or linkage editor)によるリンク処理(link)が行われる。この時に、printf()やscanf() の機械語(組み込み関数などのライブラリの内容)が実行プログラム a.out の中に埋め込まれる。通常は、コンパイルとリンク処理は一連の処理として実行される。

helloworld.c ソースプログラム
  ↓ compiler $ gcc -c helloworld.c  (コンパイルだけ行う)
　↓　　　　　　　ただしC言語では、コンパイルの前にプリプロセッサ処理 #include,#define の処理が行われる。
helloworld.o オブジェクトファイル(中間コード)
  ↓ linker   $ gcc helloworld.o     (リンク処理を行う)
 (+) ← libgcc.a ライブラリ(printf, scanf....)
  ↓          $ ./a.out
a.out 実行プログラム

静的リンクライブラリと動的リンクライブラリ

しかし、printf() や scanf() のような組み込み関数の機械語が実行プログラムの中に単純に埋め込まれると、

• よく使われるprintf()やscanf()の処理は、沢山の実行プログラムの中に埋め込まれる。
  そして、組み込み関数を使ったプログラムが複数実行されると、実行中のメモリに複数の組み込み関数の処理が配置されてメモリの無駄が発生する。
• その組み込み関数に間違いがあった場合、その組み込み関数を使った実行プログラムをすべて再コンパイルしないといけなくなる。

リンクされたプログラムの機械語が実行プログラムに埋め込まれる方式は、静的リンクライブラリと呼ぶ。

しかし、静的リンクライブラリの方式は、実行時の命令の領域のムダや、ライブラリに間違いがあった場合の再コンパイルの手間があるため、動的リンクライブラリ方式(共有ライブラリ方式)がとられる。

動的リンクライブラリでは、プログラム内には動的リンクを参照するための必要最小限の命令が埋め込まれ、命令の実体は OS が動的リンクライブラリとして管理する。

Linux では、静的リンクライブラリのファイルは、lib～.a といった名前で保存され、動的リンクライブラリは、lib～.so という名前で保存されている。 Windows であれば、拡張子が ～.DLL のファイルが動的リンクライブラリである。

OS にとって必須の動的リンクライブラリは /lib 配下に保存されるが、ユーザが独自にインストールするパッケージの場合 /lib のアクセス権限の都合で別の場所に保存されるかもしれない。この場合、その独自パッケージを起動する時に、動的リンクライブラリの保存場所を見つけ出す必要がある。Linux では 環境変数 LD_LIBRARY_PATH に自分が利用する動的リンクライブラリの保存場所を記載すれば、OS がプログラム起動時に動的リンクライブラリを見つけてくれる。

Javaのコンパイル と JIT と CLASSPATH

Java のプログラムを実行する場合は、以下のような流れで実行される。

Main.java ソースプログラム
 ↓ コンパイラ $ javac Main.java
Main.class Javaバイトコード
 ↓ JVM実行    $ java Main (Main.classを実行)
JIT (Just In Time コンパイラ)
 ↓ バイトコードを機械語に変換
機械語を実行

この場合、複数のファイルに分割された Java のプログラムであれば、以下のように分割、実行となる。

((( ListNode.java )))
import java.util.* ;

class ListNode {
   int      data ;
   ListNode next ;
   ListNode( int d , ListNode n ) {
       this.data = d ;
       this.next = n ;
   }
    static void print( ListNode p ) {
        for( ; p != null ; p = p.next )
            System.out.print( p.data + " " ) ;
        System.out.println() ;
    }
} ;

((( Main.java )))
import java.util.* ;
public class Main {
    public static void main(String[] args) throws Exception {
        ListNode a = new ListNode( 11 , new ListNode( 22 , new ListNode( 33 , null ) ) ) ;
        ListNode.print( a ) ;
    }
}

((( コンパイルと実行 )))
$ javac ListNode.java
$ javac Main.java
$ java  Main

この時、ListNode.java , ListNode.class を別フォルダ(例えば module/ListNode.java に保存する場合、java Main にてプログラムを実行する際に、ListNode.class が見つからないといったエラーが出てくる。こういった場合には、javac –classpath module Main.java とか、java –classpath module Main といったように実行するか、環境変数 CLASSPATH に、export CLASSPATH=module:その他… といったように実行に必要な class ファイルが保存されている場所を登録しておく必要がある。

分割コンパイル

複数人でプログラムを開発する場合、1つのファイルを全員で編集するのは混乱してしまう。例えば、ちょうど情報構造論で説明している、リスト処理のようなプログラムであれば、List 構造の構造体、cons(),print() といったList 構造を操作する関数を作る人と、そのそれらの関数を利用するプログラムを書く人に分かれてプログラム開発をすれば混乱も減らせる。そして、それぞれ別のファイルになっている方が開発しやすい。

• list.h : ヘッダファイル – 構造体の宣言や関数のプロトタイプ宣言や変数のextern宣言などを記載
• list.c : リスト処理の cons,print などの処理内容を記載
• main.c : cons,print を使った処理を記載

#include “ヘッダファイル”

自作のヘッダファイルを読み込む場合は、#include “list.h“ のように記載する。

#include で、ヘッダファイルを < > で囲むと、/usr/include フォルダから探してくれる。” “ で囲むと、ソースプログラムと同じフォルダの中からヘッダファイルを探す。

プロトタイプ宣言と extern 宣言

ヘッダファイルには、list.c と main.c の両方で使われるデータ構造、関数、変数の宣言を記載する。関数は、引数の型や返り値の型を記載した struct List* cons( int , struct List*) ; といったプロトタイプ宣言を記載する。変数については、変数の型だけを宣言する extern struct List* stack ; といった extern 宣言を記載する。

// list.h -----------------------------
// リスト構造の宣言
struct List {
  int data ;
  struct List* next ;
} ;

// リスト操作の関数のプロトタイプ宣言
extern struct List* cons( int , struct List* ) ;
extern void print( struct List* ) ;

// stack の extern 宣言
extern struct List* stack ;

// スタック操作関数のプロトタイプ宣言
extern void push( int ) ;
extern int  pop() 

// list.c -----------------------------
#include <stdio.h>
#include <stdlib.h>

#include "list.hxx"

// リストの要素を作る
struct List* cons( int x , struct List* n ) {
  struct List* ans = (struct List*)malloc( sizeof( struct List ) ) ;
  if ( ans != NULL ) {
    ans->data = x ;
    ans->next = n ;
  }
  return ans ;
}
// 全要素の出力
void print( struct List* p ) {
  for( ; p != NULL ; p = p->next )
    printf( "%d " , p->data ) ;
  printf( "\n" ) ;
}
// stack の実体
struct List* stack = NULL ;
// スタックに x を保存
void push( int x ) {
  stack = cons( x , stack ) ;
}
// スタックの先頭を取り出す
int pop() {
  int ans = stack->data ;
  struct List* d = stack ;
  stack = stack->next ;
  free( d ) ;
  return ans ;
}

// main.c -----------------------------
#include <stdio.h>

#include "list.hxx"

int main() {
  struct List* top = cons( 1 , cons( 2 , cons( 3 , NULL ) ) ) ;
  print( top ) ;

  push( 11 ) ; push( 22 ) ; push( 33 ) ;
  printf( "%d\n" , pop() ) ;
  printf( "%d\n" , pop() ) ;
  printf( "%d\n" , pop() ) ;
  return 0 ;
}

分割コンパイルの作業を確認するために、以下のコマンドを実行してみよう。

((( 一度にコンパイルする方法 )))
guest00@nitfcei:~$ cp /home0/Challenge/seg-compile/* .
guest00@nitfcei:~$ gcc list.c main.c
guest00@nitfcei:~$ ./a.out
# 正しく実行できる。
 
((( 失敗するコンパイル )))
guest00@nitfcei:~$ gcc list.c
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o: in function `_start':
(.text+0x24): undefined reference to `main'
collect2: error: ld returned 1 exit status
# list.c の中に main() が無いからエラー
 
guest00@nitfcei:~$ gcc main.c
/usr/bin/ld: /tmp/ccxr4Fif.o: in function `main':
main.c:(.text+0x17): undefined reference to `cons'
/usr/bin/ld: main.c:(.text+0x24): undefined reference to `cons'
/usr/bin/ld: main.c:(.text+0x41): undefined reference to `print'
:
collect2: error: ld returned 1 exit status
# main.c の中に、cons(),print(),push(),pop() が無いからエラー
 
((( プログラムをひとつづつコンパイル )))
guest00@nitfcei:~$ gcc -c list.c           # list.o を作る
guest00@nitfcei:~$ gcc -c main.c           # main.o を作る
guest00@nitfcei:~$ gcc list.o main.o       # list.o と main.o から a.out を作る
guest00@nitfcei:~$ ./a.out
# 正しく実行できる。

make と Makefile

上記のように分割コンパイルのためにファイルを分割すると、実行プログラムを生成するには以下のコマンドを実行する必要がある。

1. gcc -c list.c        (list.o を作る)
2. gcc -c main.c     (main.o を作る)
3. gcc list.o main.o (list.oとmain.oを使って a.out を作る)

また、プログラムのデバッグ作業中ですでに list.o , main.o , a.out が生成されている状態で、main.c の中に間違いを見つけて修正した場合、list.o を作るための 手順1 は不要となる。例えば list.c が巨大なプログラムであれば、手順1を省略できれば、コンパイル時間も短くできる。一方で、どのファイルを編集したから、どの手順は不要…といった判断をプログラマーが考えるのは面倒だったりする。

こういった一部の修正の場合に、必要最小限の手順で目的の実行プログラムを生成するためのツールが make であり、どのファイルを利用してどのファイルが作られるのかといった依存関係と、どういった手順を実行するのかといったことを記述するファイルが Makefile である。

### Makefile ###
# a.out を作るには list.o , main.o が必要
a.out:  list.o main.o      # 最終的に生成する a.out の依存関係を最初に書く
        gcc list.o main.o

# list.o は list.c , list.h に依存
list.o: list.c list.h
        gcc -c list.c

# main.o は main.c , list.h に依存
main.o: main.c list.h
        gcc -c main.c

clean:; rm *.o a.out       # 仮想ターゲット: make clean と打つと、rm *.o a.out を実行してくれる。

• list.h , list.c , main.c , Makefile

Makefile では、依存関係と処理を以下の様に記載する。make コマンドは、ディレクトリ内の Makefile を読み込み、ターゲットファイルのタイムスタンプと依存ファイルのタイムスタンプを比較し、依存ファイルの方が新しい場合(もしくはターゲットファイルが無い場合)、ターゲットを生成するための処理が行われる。

ターゲットファイル: 依存ファイル ...
      ターゲットファイルを生成する処理    # 行の先頭の空白は"タブ"を使うこと

理解確認

• 理解確認のForms(ライブラリと分割コンパイル)