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

[Joachim S]

Hallo Zusammen,

es geht um Delphi 10.3, um Windows-Plattform mit VCL.

wir benutzen da eine "Basissoftware", deren Dateien alle in der Projektverwaltung angelegt sind.

Bei Projekt erstellen werden die auch brav alle durchcompiliert.

Hinzu kommen jedoch kundenspezifische Teile, die wir aus allerlei Gründen nicht in der Projektverwaltung anmelden wollen.

Wenn ich nun Compilerbedingungen definiere, möchte ich, dass auch diese Dateien mit den neuen Bedingungen neu compiliert werden.

Gibts da eine Option, die ich noch nicht gefunden habe? Bislang behelfen wir uns da mit dem Löschen der DCUs, oder indem wir in den Quelltext noch ein Leerzeichen hauen, damit er "neuer" als seine DCU wird.

Hoffe, meine Frage war verständlich...

Und nein, es ist keine Spinnerei, es ist im Prinzip wirklich praktisch, diese Dateien nicht in der Projektverwaltung zu haben ;-)

Viele Grüße, Jo

[himitsu]

Ja, über den FinalBuilder lasse ich auch mehrere PAS einzeln kompilieren (übergebe sie dort der dcc32.exe)
und anschließend können mehrere Projekte parallel (früher dcc32 und nun msbuild) kompiliert werden, welche nur noch die DCUs in ihrem Suchpfad haben,
anstatt alle versuchen diese PAS zu kompilieren und sich dadurch gegenseitig die "gleiche" Datei klauten/überschieben, da mit dem selben globalen DCU-Ausgabepfad.




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

Lösungen:
* alle Dateien in ein Projekt aufnehmen und das kompilieren
oder
* die Units (PAS) manuell an den jeweiligen Compiler (dcc*.exe) übergeben



PS: es wäre auch möglich je Kompilerbedingung ein anders Ausgabeverzeichnis zu nutzen
und beim Kompilieren der Projekte entsprechend das passende Suchverzeichnis.

Also je nach CompilerDefine-Mix ein anderes Verzeichnis, so wie man auch je nach Config und Platform unterschiedliche Verzeichnisse nutzen kann/sollte.





direkt einer dcc*.exe eine *.dpr, *.dpk oder eben eine pure *.pas geben

oder msbuild nimmt die *.dproj entgegen und übergibt sie an die jeweilige dcc*.exe, mit der entsprechenden *.dpr oder *.dpk

oder msbuild bekommt die *.groupproj und kompiliert daraus mehrere *.dproj (also *.dpk und *.dpr an die jeweiligen dcc*.exen)

[Sinspin]

Zitat:

Zitat von himitsu (Beitrag 1524544)

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:

Zitat von Sinspin (Beitrag 1524550)

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:

Zitat von himitsu (Beitrag 1524560)

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:

Zitat von Joachim S (Beitrag 1524556)

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:

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.