プロジェクトのフォルダ構成
解決プロジェクトのフォルダはどのように分けたら良いのでしょう？
私は\source, \bin, \doc程度しか分けてないのですが
みなさんはどのようにしていますか？
他の環境に移植したり、他人に引継ぎなどした場合、デフォルト以外の
設定を行っていると不具合が出やすいので、可能な限りデフォルトの
まま（＝インストール状態のまま，Delphiが勝手に作成するまま）に
しています。
プロジェクトは自分が作ったプログラムのことですか？
私はデスクトップ上にフォルダを作っています。
他はデフォルトです
deldelさん,三輪一雄さん。ありがとうございます。
> プロジェクトは自分が作ったプログラムのことですか？
はい。自分で作っているプログラムの開発時のソースファイルの置き場所、
EXEファイルの出力場所などの質問です。
私の場合、Delphi以外のプロジェクトも扱うので、
\projectsの下に、
\projects\delphi\
\projects\vb6\
\projects\vbnet\
\projects\vc\
\projects\java\
というようにフォルダ分けし、
\projects\delphi\
の中にプロジェクト毎のフォルダを作っています。
別環境への移行が楽なように、特にそれ以上のフォルダはわけていません。
Delphiで管理しないファイルは、
\projects\delphi\[プロジェクト名]\resource\
\projects\delphi\[プロジェクト名]\setup\
\projects\delphi\[プロジェクト名]\doc\
というように分けることはありますが、基本はそのままです。
下手にソースを分けると、オプションを変更してパスを通さないといけないですし。
各プロジェクトで共通に使うモジュールは、別に置いてます。こちらは、Delphiのライブラリパスを通して使用しています。
わたしはD:\(マイドキュメントに設定している)の直下にprogrammingというフォルダをつくり
D:\programming\delphi\[プロジェクトグループ名]\[プロジェクト名]\[プロジェクト].dpr
D:\programming\delphi\[プロジェクトグループ名]\[プロジェクト名]\resource\
D:\programming\delphi\[プロジェクトグループ名]\[プロジェクト名]\dialog\
D:\programming\delphi\[プロジェクトグループ名]\[プロジェクト名]\frames\
としてます。わたしもにしのさんと同じくほかの言語も使うので、言語ごとにわけてます。
プロジェクトグループ名のフォルダの下にプロジェクト名のフォルダを作るのは、ソフトのプラグインなどを作るときのため。
プロジェクト共通のユニットは
D:\programming\delphi\common modules\~~.pas
においてパスを通してますね。
にしのさん, たかみちえさん, ありがとうございます。
> 別環境への移行が楽なように、
移行の事は考えていませんでした。勉強になります。
> こちらは、Delphiのライブラリパスを通して使用しています。
これはちょっと分かりませんでした。
ライブラリパスの設定はコンポーネントをインストールした時しかやった事が無いのですが
他にも設定が必要な場合があるのでしょうか？
> プロジェクト共通のユニット
確かにこれも必要ですね。勉強になります。
ひとつ心配なのは共通のユニットが成長していった場合、古いプロジェクトと整合が保てなくなるという事です。
これはあまり問題ないのでしょうか？皆さんはどう対処されていますか？
X: 適当なドライブと考えてください。通常は D:\ですけど。
プロジェクト
X:\<省略>\Delphi\[プロジェクト名]\[プロジェクト].dpr
ヘルプファイル
X:\<省略>\Delphi\[プロジェクト名]\Help\
コンパイル済みユニット出力先
X:\<省略>\Delphi\[プロジェクト名]\object\*.dcu
ソース等履歴保存用
X:\<省略>\Delphi\[プロジェクト名]\his\
インターネットで拾ってきたサンプル等
X:\<省略>\Delphi\[プロジェクト名]\sample\
リソースファイル(リソースファイルを作成する場合のみ)
X:\<省略>\Delphi\[プロジェクト名]\Resource\
共通ユニット(PCによって違う(^^ゞ)
あらゆるコンポーネントがごちゃ混ぜ
X:\<省略>\Delphi\Lib
X:\Delphi\Lib
共通ユニットテスト用(拾ってきたコンポーネントのテストインストール用)
いるものも、いらないものも、果てしなくごちゃ混ぜ
X:\<省略>\Delphi\LibTest
X:\Delphi\LibTest
> ひとつ心配なのは共通のユニットが成長していった場合、古いプロジェクトと整合が保てなくなるという事です。
できる限り下位互換性？を保つように育成する。
overload で、引数の型、数が異なる関数を増やす。
そもそも、整合がとれなくなるような改変は行わない。
というか・・・成長って、どういう意味？
ぬのさん, ありがとうございます。
> そもそも、整合がとれなくなるような改変は行わない。
なるほどそういう努力が必要なのですね。勉強になります。
> というか・・・成長って、どういう意味？
プロジェクトを経るごとに機能が追加され, ライブラリの規模が拡大していくけど, 変更した事も忘れていく
ある日、昔のプロジェクトを開くと・・・というようなイメージです。
> コンパイル済みユニット出力先
これは私も気になっていました。やはりdcuはあちこちに散らからない方が良いのでしょうか。
> > コンパイル済みユニット出力先
> これは私も気になっていました。やはりdcuはあちこちに散らからない方が良いのでしょうか。
当方 まだまだDelphi5使いなんですが、プロジェクトオプションで
「ユニット出力ディレクトリ」に「.\object」を指定しています。
個人的に「dcuをpasと同じ場所に置きたくない(作成して欲しくない)」ので、
どこかにまとめて出力するようにしたいのです。
ところが、私の上記のような乱雑開発環境のため、ソースを丸ごと他のPCに
移動することになると、ユニット出力ディレクトリがPCごとに違う場所を
指すため、移行する毎にユニット出力ディレクトリを変更するなどという
なさけない状況になるわけです。
それがイヤでプロジェクトの直下のフォルダに出力するようにしています。
そうすれば、どこに行っても出力先が固定ですから。
あと、複数の共通ユニットがありますが、小さいプロジェクトなら、
どれとどれを使っているかわかりやすいなぁ・・・と。
> > というか・・・成長って、どういう意味？
> プロジェクトを経るごとに機能が追加され, ライブラリの規模が拡大していくけど, 変更した事も忘れていく
> ある日、昔のプロジェクトを開くと・・・というようなイメージです。
触らぬ神に祟りなし・・・ですが、よくわからずに回答した
> できる限り下位互換性？を保つように育成する。
> overload で、引数の型、数が異なる関数を増やす。
これでいくしかないのでは？
整合性については、ぬのさんと同意見です。ユニットを更新するにしても、古いプロジェクトで影響が出ないように、ちゃんと下位互換性を保っていく必要があります。
基本的にはぬのさんの言うとおりの方法が適切だと思います。とにかく前のバージョンのユニットを使ったプロジェクトが、新しいバージョンのユニットを使っても正常にコンパイルできて、動作できること。ですね。
どうしても無理な場合や、大幅に方針変更する場合は、今までのユニット丸ごと「古いもの」として、全く新しいユニットを作るなども考えるべきでしょう。
dcuファイルは、わたしはプロジェクトオプションで、
D:\Programming\Workspace に移動するようにしています。んで、これらは配布時には含めない と。
わたしは「ソフト公開時はオープンソースで」というのがポリシーみたいなものになってるので、常に別環境で使用することを考えてソースを配置してます。
共有モジュールは別途配布するようにして、各自パスの通ったフォルダ(ツール＞環境オプションより設定可)に置いてもらう ということにします。公にするものだから、なおのこところころしようが変わるなんてことは許されません。そういう意味では身も引き締まるやり方ですね。
ぬのさん, たかみちえさん, ありがとうございます。
> わたしは「ソフト公開時はオープンソースで」というのがポリシー
公開のことも考える必要がありますね。勉強になります。
> これでいくしかないのでは？
他に考え付いたのは, 共通ライブラリにバージョンをつけ（Subversionで管理？）
バージョン間では「互換性は（たぶん）あるけど保証はしない」という事にして（笑）
共通ライブラリを使用する際は, プロジェクトごとにプロジェクト\共通ライブラリへコピーする
（共通だけど共有はしない）という方法です。
> 各自パスの通ったフォルダ(ツール＞環境オプションより設定可)に置いてもらう
これが良く分からないのですが, 実行時パッケージを使っているという事でしょうか？
自己レスです。
> これが良く分からないのですが
分かりました。SysUtilsのように, プロジェクトに明示的に追加しなくてもIDEを起動しただけで, 使えるユニットという事ですね。
今までそういう発想はなかったので、非常に勉強になりました。
> バージョン間では「互換性は（たぶん）あるけど保証はしない」という事にして（笑）
それはいいですが、じきに自分の首を絞めることになります。
バージョンごとに非互換の可能性があるとしたら、ユニットバージョンがあがるたびに、すべてのプロジェクトの保守作業をしなければならない というメに遭います(わたしはこれについてはVBで経験済み。今の都合ばかり考えて共通モジュールの機能拡張をしたせいで、古いプロジェクトを開くたびにメンテに一日かかるという事態になりました。いくら好きでやってるプログラミングだとしても、それは気が萎えるってものです(^_^;))。
そうなると、バージョンごとに別ユニットとして管理しなくてはいけない。配布も下手をしたら全バージョン配布しなければいけないわで、いいことはないです。それなら別の名前で配布したほうが良くなってしまいますね。
たかみちえさん, ありがとうございます。
> それはいいですが、じきに自分の首を絞めることになります。
確かにバージョンを上げる時は大変そうです。
ブランチはともかく, 主トランクで互換性が無いというのは「ありえない」という事ですね。気をつけます。
回答して下さった皆さん, ありがとうございました。解決とさせて頂きます。
| ツイート |  |