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

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

Zitat von Sinspin (Beitrag 1524575)

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.

[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

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



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 ... :party:

[Joachim S]

Pre-Build-Befehle...

Gerade unter Projekt-Optionen gesehen, dass es sowas gibt.

Ist das mein Freund? Kann ich da was Eigenes definieren?

Tschuldigung, wenn die Frage dumm ist. Ich befasse mich halt zum Ersten Mal näher damit ;-)

Gruß Jo

Nachtrag: OK, ich hab selbst gegoogelt. Offenbar kann man gültige Dos-Befehle eintragen. Das sollte doch mein Problem lösen. Ich probiere mal damit rum, und gebe Rückmeldung...

[Joachim S]

Danke an Alle fürs Mitgrübeln,

die Pre-Build-Ereignisse lösen das Problem.

einfach "del \\Blabla\MeinShareOrder\*.dcu" dort eingetragen, und es tut, was es soll.

Ein Teil der Probleme beruht offenbar auch darauf, dass die Uhren der Maschinen und meines Notebooks nicht synchron laufen.

Das vorherige Löschen der DCUs hilft jedenfalls immer.

Danke und Gruß an Alle.

[himitsu]

Du mußt aufpassen, denn diese sind inzwischen auch config-abhängig.
Am Besten immer auf "Basis" umschalten, bevor du etwas machst.

Hier rufe ich dort aber bloß noch ein Batch (*.cmd) auf,
weil es irgendwie nervt, wenn man da bei über 100 Projekten etwas ändern muß.
Wie haben hier eine Projektgruppe mit vielen Projekten (DLL/BPL/EXE).
Und noch Eine mit den Fremdkomponenten.






mein PostBuildScript (Tipp: rechts, den kleinen Button, für das Edit-Fenster)

Code:

"$(root)\_BuildTools\dproj__compile_postbuild.cmd" "$(Config)" "$(Platform)" "$(OutputExt)" "$(InputDir)$(InputName)" "$(OutputDir)$(OutputName)"

$(InputDir)$(InputName) anstatt $(InputName) oder $(InputFileName) hat gewisse Gründe, vor allem wegen einige Bugs bezüglich der PackageVersion beim {$LIBSUFFIX AUTO} :wand:

Und %root% ist eime Umgebungsvariable
aus Tools > Optionen > IDE > Umgebungsvariablen , bzw. HKEY_CURRENT_USER\SOFTWARE\Embarcadero\BDS\22.0\En vironment Variables
oder eben auch aus [Win]-Taste + "Umgebungsvariablen"



und in die dproj__compile_postbuild.cmd einfach mal das rein

Code:

echo %*
exit 1

Dort drin dann z.B. den Eurekalog-PostProcess, die Signierung der Dateien und teilweise das Umkopieren.