1

プロジェクトをビルドすると、コンパイルの進行中にすべてのユニットが再コンパイルされることを期待しています。プロジェクトを「作成」するとき、ソースに変更があるユニットのみを再コンパイルする必要があります。完全なビルドの直後に作成すると、リンクが発生し、他に何も表示されないことが期待されます。

何らかの理由で、Delphi は特定のユニットを再コンパイルすることに頭を悩ませています。私が過去に気付いた主なものはidIOHandler.pas、インディの一部です。他のものをコンパイルすることもあります - 常に Indy のユニットです。Indy のソース フォルダーを検索して、日付スタンプがおかしいファイルを探しましたが、無駄でした。

(ときどき、逆の問題が発生します。変更したことがわかっているソース ユニットが再コンパイルされない場合があります。これは、PC とソースが保持されているサーバーとの間の時間差によるものです。)

大したことではありませんが、説明を聞きたいと思います。

4

3 に答える 3

3

再コンパイルが必要かどうかは、Delphi がどのように判断するかに完全に依存します。

これを引き起こす原因が1つあります（完全に非Delphi環境で）。何らかの理由で、ファイルに将来の日付が指定されている場合、それらに依存するファイルは常に再コンパイルされます。

たとえば、何らかの理由myprog.cで に 2027 年の日付が指定されているとします。最初に ( にmyprog.o) コンパイルすると、結果は 2013 年の今日の日付になります。

次にmake を実行すると、日付が の日付よりもmyprog.c後になり、myprog.oそのために再コンパイルされます。

それが問題の原因かどうかはわかりませんが、調べる価値があるかもしれません。

もう一つ気をつけなければならないこと。インターフェースが変更された別のユニットにユニットが依存している場合は、再コンパイルされます。別の質問に対するこの回答も参照してください。ただし、これにも関連する情報が提供されます。

私はコンピューターを信用していないので、ほとんどの場合フル ビルドを行う傾向があります。

于 2013-04-28T06:48:40.777 に答える
2

残念ながら、Delphi コンパイラとその依存関係のソース コードはクローズド ソースであるため、この質問には憶測が必要です。ただし、Indy ユニットの再コンパイルを回避したい場合は、もちろん DCU ファイルのみをライブラリ パスに配置し、検索パス (プロジェクト レベル) とライブラリ パス (グローバル IDE レベル) から Indy ソース ファイルを削除することもできます。構成。マップされたネットワーク ドライブ間でソース コードを実際にコンパイルしている場合は、気が狂っていると思います。Mercurial と、レポジトリを複製し、すべてのソース コードのコピーをビルド元の同じコンピューターに完全に保持できるこのクールな機能をチェックすることをお勧めします。かっこいいね。

とにかく、コンパイラ...これまでに観察したことは次のとおりです。

  1. あなた (および私) にとって再コンパイルのように見えるものは、実際にはおそらく Interface セクションのスキャンにすぎず、実際には依存関係のツリーが構築される方法です。C (makefile) または Java (ant または maven) スタイルのビルド環境とは異なり、特定のモジュールのすべての依存関係を見つけるには、少なくともコードのインターフェイス セクションでコンパイラを緩く設定することが唯一の方法です。検索パスから Indy ユニットを削除しても、 の「コンパイル」を示すコンパイラの進行状況が表示される場合があると思いますIdIOHandler.pasが、この場合、それが行うことは、あなたのインターフェイス セクションのコンパイル済み表現をロードすることです。 DCU ファイルからパスカル単位を取得し、次にどのファイルを読み取るかを決定します。場合によっては、IDE の進行状況がユニットで「コンパイル中」と表示されますが、最後に DCU ファイルが変更されません。

  2. いくつかの重大な変更の後、大規模なプロジェクトをリファクタリングまたは修正するために大規模な戦いを繰り広げているとき、私は次のことを観察しました。次の構文エラーがコンパイルを中断する場所を推測することは、不可能ではないにしても非常に困難です。b. コンパイラがユニット A の致命的なエラーで中断し、次にユニット B の途中で、次に再びユニット A で、次にユニット C で、次に再びユニット B で中断するということは、コンパイラが、C コンパイラのメンタル モデルが基にしているようなものではないことを示唆しています。最初にユニット A をコンパイルし、次にユニット B をコンパイルし、次にユニット D をコンパイルします。私が持っているすべての証拠は、実際のプロセスはこれよりもはるかに複雑であることを示唆しています。ファイルAの「シングルパス」を呼び出し、他のファイルのコンテンツの「スキャン」または他のファイルのスキャンがあります。メモリ内の内部表現 (物理ファイルの内容の解析ではなく) は、「コンパイル」がすべてかゼロか、すべて一度に行われるものではなく、むしろ大きなメモリ内ですべてが解放されることにつながり、コンパイラの順序は次のとおりです。ユニットの評価は、インターフェイスによって構築されたメモリ内ツリーによって駆動され、次に各ユニットの実装句によって駆動されます。実世界のアプリケーションでこの大きな循環グラフの動作を予測することは、私のスキルを超えています。

于 2013-04-28T13:12:44.830 に答える