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

[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.

[himitsu]

Wenn man bei einer EXE auch diese {$LIBPREFIX}, {$LIBSUFFIX} und {$LIBVERSION} verwenden könnte,
oder das {$EXTENSION} mit mehr als 4 Zeichen (inkl. Punkt), dann wäre es doch zu geil, niwa?
Oder den Ausgabenamen komplett neu zuweisen könnte (geht, aber nicht schön), via IFDEF bzw. besser noch in den verschiedenen Projektoptionen......

Alternativ kann man es aber auch im AfterBuild-Script umbenennen/umkopieren ... nur wäre es schön, wenn dann in den "inzwischen config-abhängigen" Start-Parametern das mit der Host-Anwendung bei der EXE auch richtig funktionieren würde.



Ansonsten, finde ich gegenüber einem .\$(Platform)\$(Config) es eindimensional irgendwie angenehmer/übersichtlicher, wenn die verschieden Varianten direkt nebeneinander sind,
also .\$(Platform)_$(Config) bzw. .\_$(Platform)_$(Config) oder z.B. .\_Compiled\$(Platform)_$(Config)

Und es wäre super, wenn Delphi selber Variablen für seine Version und das GroupProjekt-Verzeichnis anbieten täte. (hier über Environment-Variablen im FinalBuilder für MSBUILD, bzw. einer Kopie in der Delphi-Registry gelöst, welche der FinalBuilder da reinschreibt)



GruppenProjekt mit massig BPLs, DLLs und einigen EXEn, wobei die Ausgabepfade zentral/global liegen.
%root%\_Compiled\%ver0%_$(Platform)_$(Config)_DCU
%root%\_Compiled\%ver0%_$(Platform)_$(Config)_DCP
%root%\_Compiled\%ver0%_$(Platform)_$(Config)_BPL <- FremdComponenten, die nicht jedesmal neu kompiliert werden
%root%\_Compiled\Run oder vielleicht %root%\_Run <- EXE, DLL und BPL, sowie Kopieen aus dem aktuell passenden _BPL und weiteren Dateien (z.B. 7z.exe) ... was der FinalBuilder erledigt
Und von _DCU und _DCP eine Backup-ZIP, nach dem Neukompilieren der Fremdkomponenten, um vor dem kurzen Kompilieren es zurückzusetzen. (alternativ mehrere _DCU und _DCP, für Fremd- und Eigen-Projekte ... aber ist hier halt historisch so, nur dass ich inzwischen noch das Backup mache, um vorher schnell ausmisten/zurücksetze zu können)
Hab die letzten Jahre hier aufgeräumt ... alle Verzeichnisse mit einem _ oder zwei __ am Anfang, werden von GIT ignoriert und lassen sich zum Aufräumen einfach löschen.

Seit _DCU und Co. auch noch die Versionsnummer der Delphi-IDE, bzw. genauer die PackageVersionsNummer enthalten, lassen sich unterschiedliche Delphis hier auch wieder gleichzeitig nutzen, ohne vorher mit dem FinalBuilder ...

[Joachim S]

HI Zusammen,

erstmal Danke an alle für die rege Beteiligung.

Ja, natürlich mache ich ein Build.

Ja, jede Maschine hat ihr eigenes Verzeichnis, in dem die compilierten Units und die exe abgelegt werden. Nur der Share-Ordner ist woanders im Netzwerk. Und dort entstehen auch die DCUs der .pas-Dateien des Share-Ordners.

Zum Verständnis, ich öffne jeweils das Projekt auf der konkreten Maschine. Dort sind unter den Projektoptionen dann abweichende Compiler-Bedingungen deklariert. Wenn ich dann das Projekt erstelle (Build), wir z.B. der Share-Ordner nicht zuverlässig durchcompiliert. Soweit seine Dateien eben nicht zum Projekt gehören.

Und dann knallt es eben, weil die geänderten Direktiven schon wichtig sind...

Klar, ich kenne das längst und komme klar, die kritischen Dateien kenne ich ja, und haue ein Leerzeichen rein. Dann sind sie jünger als die DCUs und werden compiliert.

Aber manchmal vergesse ich eben Eine, oder alle. Deshalb suche ich nach ner Lösung.

Offenbar hat Delphi nichts an Bord, sonst hätte es bestimmt schon jemand gewusst

Was mir gerade durch den Kopf geht. Ich öffne die Projekte auf den einzelnen Maschinen üblicherweise per Doppelklick auf die .dproj. Ich könnte ja auch ne Batch starten, die zuerst die kritischen DCUs löscht, und dann erst Delphi startet? Dann muss ich aber auch immer dran denken, Delphi NUR über diese Batch zu starten...

Gruß Jo