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