一般的な開発ディレクトリの構造（ソースとバイナリの配置） [not JAVA]

投稿者

投稿内容

ひろ１８号: 会議室デビュー日: 2005/02/02; 投稿数: 5

投稿日時: 2005-02-02 20:25

ひろ１８号と申します。
開発ディレクトリの構造についてご教示ください。
開発時のソースファイルのツリーと
リリース時のバイナリファイルのツリーを
どのような構造にすれば管理がすっきりするでしょうか？
参考文献など探しているのですが深く解説しているものが見つかりません。
言語はＣ＋＋です。ＯＳはＨＰ－ＵＸです。

考えているうちにどんどん深みにはまって下のように拡散してしまってます。
いくつかのサブシステムからなるシステムです。
includeの場所は？srcと別？libは？makefileは？バイナリはどこへ？共通するソースは？
フリーのソースツリーみたり見よう見まねで指向錯誤中。
制約があってconfigureとかautomakeとか使える環境ではないので
makefileの書き方なども勉強中。

SystemA/
　　include/
　　　　Common.h
　　bin/
　　　　SystemA.out, SubSystemA.out, SubSystemB.out, SubSystemB.out
　　lib/
　　　　Common.lib
　　cfg/
　　　　SystemA.cfg
　　src/
　　　　Common/
　　　　　　include/
　　　　　　　　Common.h
　　　　　　src/
　　　　　　　　Common1.cpp Common2.cpp
　　　　　　bin/
　　　　　　　　Common.lib
　　　　SubSystemA/
　　　　　　include/
　　　　　　　　SubSystemA.h
　　　　　　src/
　　　　　　　　SubSystemA1.cpp SubSystemA2.cpp
　　　　　　bin/
　　　　　　　　SubSystemA1.out
　　　　SubSystemB/
　　　　SubSystemC/

ひろ１８号: 会議室デビュー日: 2005/02/02; 投稿数: 5

投稿日時: 2005-02-02 20:31

ひろ１８号と申します。
建て続けにすみません。
参考文献でもよろしいのでお願いします。
階層化した共有ライブラリの管理が手に負えなくなってきた。
検索するとJavaが多いな・・・。

Gio: ぬし; 会議室デビュー日: 2003/11/28; 投稿数: 350; お住まい・勤務地: 都内から横浜の間に少量発生中

投稿日時: 2005-02-02 21:15

確かに、参考にできる資料は少ないと思います。
なぜなら、プロダクト管理構造は、それこそプロジェクトマネジャやアーキテクトと呼ばれる人々が、管理コストを最適にできるよう、プロジェクトごとに自ら考えるべき事象だからであると私は考えます。いかがでしょうか。

さて、ひろ１８号さんが書かれたディレクトリ構造を拝見したところ、bin や src といった機能別ディレクトリとサブシステムディレクトリが混在しており、しかもどちらを優先すべきか混乱している印象を受けました。

サブシステム単位の独立性を重視してこちらを優先すると、以下のようにすると少しすっきりすると思います。
'#' で始まる行は私のコメントです。

makefile の書き方はオライリーの本などにあったかと思いますが、サブシステムディレクトリ直下に一つずつ置き、必要であればより下位のサブシステムのビルドに依存するように書いていくと良いかもしれません。

SystemA/
　　# システム全体のメインソースやライブラリを SystemA 直下に置く。
　　include/
　　　　SystemA.h
　　bin/
　　　　# システム全体のバイナリだけをここに置く。
　　　　SystemA.out
　　lib/
　　　　# メイン用にはライブラリディレクトリはなくても良いと思うが、
　　　　# サブシステムの出力結果ディレクトリを統一する意味で、ここに設けても
　　　　# 良いかもしれない。
　　　　SubSystemA.lib, SubSystemB.lib
　　cfg/
　　　　SystemA.cfg
　　src/
　　　　# プロダクトメインのソースを置く。
　　　　SystemA.cpp

# 以下サブシステム単位のディレクトリ
　　Common/
　　# 他のサブシステムで共通に利用するヘッダなどがあり、しかもメインが
　　# そのヘッダを参照しないならば、このような共通ディレクトリを設けても良い。
　　　　include/
　　　　　　Common.h
　　　　src/
　　　　　　Common1.cpp Common2.cpp
　　　　lib/
　　　　# サブシステムでは独立してバイナリを作らず、ライブラリを用意するだけに
　　　　# した方が良いかもしれない。
　　　　# 独立したバイナリを作るなら、それは別プロジェクトとすべきだろう。
　　　　　　Common.lib

　　SubSystemA/
　　　　include/
　　　　　　SubSystemA.h
　　　　src/
　　　　　　SubSystemA1.cpp SubSystemA2.cpp
　　　　lib/
　　　　　　# ここは元の例のまま。
　　　　　　# サブシステムのビルド結果を置くが、上述の通りメインの下にコピーする
　　　　　　# 方法もある。
　　　　　　# （サブシステムディレクトリの構造が変更されてもメインのビルドに
　　　　　　# 影響させない方法の一つとして有効。）
　　　　　　SubSystemA.lib
　　SubSystemB/
　　SubSystemC/

最後に、以上の例は、私ならこう構成するという一例に過ぎません。
ディレクトリ階層をむやみに深くしない、システムディレクトリ下の構造はメインシステムとサブシステムでなるべく共通化する、サブシステムのプロダクト（ライブラリなのか実行バイナリなのか）の位置付けを明確にするという点にポイントを置きました。
ご参考になれば幸いです。

# 誤字を修正し、SubSystemA.lib の重複に対する注釈を加えました。

[ メッセージ編集済み編集者: Gio 編集日時 2005-02-02 21:25 ]

ToGo: 常連さん; 会議室デビュー日: 2002/03/16; 投稿数: 46

投稿日時: 2005-02-06 00:51

引用:
ひろ１８号さんの書き込み (2005-02-02 20:31) より: 参考文献でもよろしいのでお願いします。階層化した共有ライブラリの管理が手に負えなくなってきた。

「大規模C++ソフトウェアデザイン」
http://www.pearsoned.co.jp/washo/prog/wa_pro15-j.html
に、中規模・大規模のソースコードディレクトリ構成について
記載されています。ヘッダーファイルの公開・非公開の区別、
ライブラリ間の依存関係の問題を扱っています。

ちいにぃ: 大ベテラン; 会議室デビュー日: 2002/05/28; 投稿数: 244

投稿日時: 2005-02-06 01:18

書籍「Code Reading―オープンソースから学ぶプログラミングテクニック」
http://www.amazon.co.jp/exec/obidos/ASIN/4839912653
http://www.linux.or.jp/bookreview/BR81.html
http://book.mycom.co.jp/book/4-8399-1265-3/4-8399-1265-3.shtml

も、直接指針を与えるものではありませんが、少し参考になるかもしれません。

一般的な開発ディレクトリの構造（ソースとバイナリの配置） [not JAVA]

スキルアップ／キャリアアップ（JOB@IT）