Alle Dateien "durchcompilieren" erzwingen, auch wenn sie nicht im Projekt sind

[Sinspin]

Zitat von himitsu:

Nein, es wird nur das kompiliert, was im Projekt drin ist.

Das ist doch Unsinn.

Ein Aufruf von "Build" erzeugt alles neu wozu Quelltexte gefunden werden. Egal ob im Projekt (also in der DPR) mit eingetragen ist. Hautpsache ist, dass es irgendwo als Unit in einer unit des Projektes mit referenziert wird.

Eines meiner Projekte hat 1430 Units in Verwendung. Davon sind gut 90 in der DPR eingetragen. Trotzdem werden die bei Aufruf von "Build" neu erzeugt.

[dummzeuch]

Wenn man wirklich paranoid ist, kann man die Dateien im DCU-Ausgabeverzeichnis löschen, dann ist sichergestellt, dass sie neu erzeugt werden.

[Joachim S]

Hi Zusammen,


Eines meiner Projekte hat 1430 Units in Verwendung. Davon sind gut 90 in der DPR eingetragen. Trotzdem w.rden die bei Aufruf von "Build" neu erzeugt.


ne, werden sie definitiv nicht. Jedenfalls nicht zuverlässig.

Es ist so, dass ich mehrere ähnliche Anlagen mit jeweils ner eigenen .exe steuere. Jede hat nen eigenen Rechner, auf dem diese Exe läuft.

Dabei benutze ich je nach Anlage andere Compiler-Definitionen, um auf die Unterschiede einzugehen. Irgendwo habe ich einen "Share-Ordner", der die gemeinsamen kundenspezifischen Quellcodeteile enthält.

Der wird leider nicht zuverlässig durchcompiliert, wenn ich zu einer anderen Maschine wechsle.

Das weiß ich definitiv. Wie gesagt, dcus löschen oder Quellcode "ändern". Dann erst gehts.

Vlt. mache ich mir ne kleine Batch oder exe, um die DCUs zu löschen... Chick wäre, wenn die IDE die vorm Erstellen selbst aufrufen könnte...

Gruß Jo

[himitsu]

Zitat von Sinspin:

Das ist doch Unsinn.

Ein Aufruf von "Build" erzeugt alles neu wozu Quelltexte gefunden werden.

Doch, es erzeugt nur das, was im Projekt ist, inkl. dem was davon eingebunden wurde und was wiederrum davon eingebunden wurde und .... aber IMMER nur das, was eben vom Projekt "benutzt" wird.

Build oder Compiler ist erstmal egal ... es wird auch nur das kompiliert, wo die PAS gefunden wird, entsprechend dem vorherigen Satz.
Beim Build immer neu und beim Compile was neu ist oder verändert wurde.

Findet der Compiler nur die DCU (zuerst) und nicht die PAS, dann wird das nicht neu kompiliert ... kann ja auch.
Und ist eine Unit nicht im Projekt, bzw. wird nicht davon benutzt, dann wird sie auch nicht kompiliert. (warum auch ... der Compiler kennt jene Unit auch nicht, bzw. will sie nicht kennen)



z.B. die hauseigenen Quellcodes des Delphi (ala Forms.pas bzw. Vcl.Forms.pas) sind standardmäßig nicht im Suchpfad des Compiler enthalten, drum werden sie eigentlich auch nie neu kompiliert.
Der Compiler findet hier normal immer nur die DCUs (oder den Link in der DCP, wenn man mit LaufzeitPackages kompiliert).
Nur der Editor hat diese PAS in "seinem" Suchpfad, damit man z.B. den Code schön im Debugger verfolgen kann.

[Uwe Raabe]

Zitat von himitsu:

es erzeugt nur das, was im Projekt ist, inkl. dem was davon eingebunden wurde und was wiederrum davon eingebunden wurde und .... aber IMMER nur das, was eben vom Projekt "benutzt" wird.

Das ist aber offenbar gegeben. Andernfalls würde das Löschen der DCUs oder das Ändern der Quellen auch nicht zu einem erneuten Compilieren führen:

Zitat von Joachim S:

Wie gesagt, dcus löschen oder Quellcode "ändern". Dann erst gehts.

Wichtig ist eben das Build - bei einem simplen Compile funktioniert es eben nur unter den genannten Bedingungen.

[Andreas13]

Für solche Fälle habe ich mehrere Dummy-Projekte mit dem Namen
__Alle_Projekte_Kompilieren.dpr
__Alle_Units_Kompilieren.dpr
angelegt, wo ich hinter Uses alle Units aufgeführt habe.
Bei mir funktioniert es gut.

[himitsu]

Und wichtig, eine geänderte INC oder ein geändertes DEFINE (in einer INC oder in den Projektoptionen) ist keine Änderung der Unit (PAS) und löst beim "Compile" auch kein Neuerzeugen aus.


Eigentlich klang Post #1 auch so, als wenn er ein "Build" durchführt.



Nja, mit dem Process Monitor von Sysinternal könnte man mal verfolgen welche PAS bzw. DCU er von wo sich vornimmt, bzw. wo er sie sucht.

[Sinspin]

Hier ist noch was anderes nicht optimal, was auch bei meinem Monsterprojekt vorhanden ist aber mindestens seit XE2 keine Probleme mehr gemacht hat :
Via Compiler directive zwischen unterschiedlichen Implementierungen zu unterscheiden.

Wenn die Schalter sauber in den Projekt Optionen eingetragen sind, klappt es. Stehen sie nur in der DPR klappt es nicht zuverlässig. Bis Heute nicht.
Allerdings finde ich das extrem grenzwertig und habe es durch aufteilen von Units auf ein absolutes minimum reduziert.

Ich finde es besser Funktionen mit Parametern/Schaltern aufzurufen, je nachdem wofür sie gebraucht werden.

Compilierst du jedes Projekt in sein eigenes Ausgabeverzeichniss für Exe und Units? Damit kann man klar erkennen was neu erstellt wurde und was nicht.

[himitsu]

In Projektoptionen, oder als Parameter an DCC*.exe bzw. msbuild.exe,
ist der Schalter überall/global verfügbar/aktiv, außer dort, wo nicht neu kompiliert wird,
oder wo er lokal in der Unit durch ein weiteres {$DEFINE} bzw. {$UNDEF} überschrieben wird.

In Projekt-Datei oder einer Unit ... Tja, nicht alle CompilerSchalter werden über UnitGrenzen durchgereicht ... eigentlich fast Keine (außer Jene, für das nachfolgende MAKE, wie z.B. die {$MAXSTACKSIZE}, {$IMAGEBASE} oder {$SetPEFlags} ), aber vor allem nicht kein {$DEFINE}.

[Uwe Raabe]

Zitat von Sinspin:

Compilierst du jedes Projekt in sein eigenes Ausgabeverzeichniss für Exe und Units? Damit kann man klar erkennen was neu erstellt wurde und was nicht.

Units, ja - Exe, nein. Aber das hat immer noch den gewünschten Effekt. Für die Exe gibt es ein gemeinsamen bin-Verzeichnis mit z.B. den nötigen Konfigurationsdateien. Damit verwenden auch unterschiedliche Kompilate immer dieselbe Umgebung. Die Units landen bei simplen Projekten in $(Platform)\$(Config) bzw. bei Projektgruppen in $(SanitizedProjectName)\$(Platform)\$(Config). Änderungen an den Defines, die ja ein neues Build erfordern, werden damit deutlich seltener und ein Projekt-, Plattform- oder Konfigurations-Wechsel erfordert nicht jedes Mal ein Build, was oft vergessen wird.