Peter18 - Di 10.05.16 10:45
Titel: Compilerproblem: Unit XX mit untersch. Vers. compiliert

---

Ein freundliches Hallo an alle,

ich habe in einer Unit (erweitertes Stringgrid) eine Methode hinzugefügt. Diese Unit wird aber in mehreren anderen Units auch verwendet. Nach dieser Änderung beschwert sich der Compiler, dass eine andere Unit mit einer anderen Version der geänderten Unit compiliert wurde. Wenn ich die Änderung zurück nehme ist alles in Ordnung. Benenne ich die ".dcu" um, beschwert er sich über das Fehlen der Datei.

Gibt es eine Möglichkeit diese Units im Projekt neu zu compilieren, ohne dass ich diese Units in einer anderen Umgebung compiliere?

Grüße von der noch immer sonnigen Nordsee

Peter

baumina - Di 10.05.16 11:00

---

Wenn du eine Komponente änderst, solltest du das Package, in der sich diese Komponente befindet, neu compilieren/installieren und danach alle Projekte, die diese Komponente benutzen überarbeiten.

Peter18 - Di 10.05.16 11:33

---

Hallo baumina,

Dank Dir für Deine Antwort. Leider habe ich diese Unit nicht in einem Package. Sie ist als Unit Teil des Projektes. Weil ich davon ausgegangen bin, dass an dieser Unit noch Erweiterungen notwendig seien könnten, dachte ich, dies wäre der weniger umständliche Weg. Typischer Fall von Denkste.

Grüße von der Nordsee

Peter

baumina - Di 10.05.16 11:44

---

Achso, dann ist das also keine Komponente, die du zur Entwurfszeit aufs Formular legst. In diesem Fall ist das eigentlich sehr einfach: Projekt neu erzeugen (Umsch+F9) und gut ist!?

Peter18 - Di 10.05.16 14:16

---

Hallo baumina,

nochmals Dank!

Doch leider Banane. Nun behauptet er .dcu nicht gefunden. Auch wenn ich in der Unit etwas ändere, sie also neu Übersetzt werden müsste klappt es nicht. :evil:

Grüße von der noch immer sonnigen Nordsee

Peter

Nersgatt - Di 10.05.16 14:21

---

Hast Du noch eine andere Datei mit dem selben Namen (mit einer anderen Endung) im Suchpfad? Oder 2 DCUs mit dem selben Namen in verschiedenen Ordnern?

Peter18 - Di 10.05.16 14:42

---

Hallo Jens,

Dank auch Dir! Ich habe nichts dergleichen gefunden. Wenn ich die .dcu verschiebe, beschwert er sich darüber, dass sie fehlt, ist sie da, meckert er über verschiedene Versionen, statt neu zu compilieren.

Sieht so aus, als müßte ich das ganze wohl doch in ein Package stopfen, oder in einer anderen Umgebung übersetzen.

Grüße von der Nordsee

Peter

jaenicke - Di 10.05.16 15:02

---

Du redest immer von der einen .dcu. Bist du sicher, dass du die richtige .dcu umbenennst? Du musst die umbenennen, die als die angezeigt wird, die mit der unterschiedlichen Version kompiliert wurde. Also nicht die von dir geänderte!

Ich vermute du hast nur die modifizierte Unit im Projekt drin, aber nicht die, die bemängelt wird und diese modifizierte Unit nutzt.

Peter18 - Di 10.05.16 15:42

---

Hallo Sebastian

auch Dir meinen Dank, leider ist es nicht so einfach: Wie schon zuvor erwähnt, kann es nur die .dcu sein, wenn ich die Quelle ändere und erhalte die Fehlermeldung, nehme die Änderung heraus und die Fehlermeldung verändert sich. Wenn ich die .dcu umbenenne oder verschiebe meckert er über die fehlende Datei. Die Suchpfade zeigen auf eine sichtbare Komponente, auf den Ordner "Obj" mit den .dcu und auf "Src" mit den Quellen. (Natürlich auch auf den Compiler) Sonst hat "Projekt/Projekt erzeugen" oder "Projekt/Projekt compilieren" auch immer geholfen, doch diesmal nicht.

Liegt das ev. an der Schachteltiefe, oder ist da etwas anderes in die Hose gegangen?? Oder ist doch ein Package angesagt??

Grüße von der Nordsee

Peter

jaenicke - Di 10.05.16 18:09

---

Wie genau lautet denn die Fehlermeldung, also mit konkreten Unitnamen?
Dann kann ich genau sagen welche Unit das Problem ist.

Peter18 - Di 10.05.16 18:35

---

Hallo Sebastian,

das Problem ist nicht welche Unit. Der Fehler wird in einer Bibliothek gemeldet, in der eigentlich nichts Großes passiert. Dort gibt es eine Reihe "procedure FreeObj" die nichts weiter tun, als ein Free mit dem Objekt auszuführen und die Objektvatiable "Nil" zu setzen. Um nicht beim Aufruf in TObjekt wandeln zu müssen, habe ich eine Reihe überladener Routinen für verschiedene Objekte, unter anderem "T_IOExcel". Er behauptet nun "T_IOExcel" wäre mit einer anderen Version von "T_StrGrid" compiliert. "T_IOExcel" benutzt "T_StrGrid".

Da scheint irgendwo ein Knoten zu sein, den ich noch nicht ganz verstehe. Daher finde ich auch keine Lösung.

Grüße von der Nordsee

Peter

jaenicke - Di 10.05.16 19:11

---

Dann muss die Unit mit T_IOExcel neu kompiliert werden. Denn die darin eingebundene Unit mit T_StrGrid hat sich geändert, so dass die .dcu mit T_IOExcel nicht mehr dazu passt.

Hast du die Unit mit T_IOExcel im Projekt drin?

Peter18 - Mi 11.05.16 10:49

---

Hallo Sebastian,

Dank Dir für Deine Antwort.

Das ist ja gerade mein Problem! Mit "Projekt/Projekt erzeugen" wird die Unit nicht übersetzt, sondern dieser Fehler gemeldet. (Befindet sich im Projekt, sonst könnte ich ja Units einzeln übersetzen) Es kann sein, dass er sich einen Fehler gemerkt hat, der zu Beginn des Problems auftrat: Die Unit konnte ich mit Delphi nicht öfnen, aber mit dem Windows-Editor, und die Unit wieder für Delphi zugänglich machen.

Wie kann ich nun Delphi dazu überreden, eine bestimmte Unit neu zu übersetzen???

Grüße von der noch immer wolkenlosen Nordsee

Peter

jaenicke - Mi 11.05.16 19:25

---

Peter18 hat folgendes geschrieben :

Wie kann ich nun Delphi dazu überreden, eine bestimmte Unit neu zu übersetzen???

Dass sie im Projekt drin sind, also beide hier betroffenen Units, sollte reichen. :nixweiss:

Im Zweifelsfall lege einfach mal ein neues Projekt an, füge die beiden Units hinzu und schaue, ob sie dann kompiliert werden.

Peter18 - Fr 03.06.16 12:53

---

Hallo Sebastian,

(Ganz oben)

Peter18 hat folgendes geschrieben :

Gibt es eine Möglichkeit diese Units im Projekt neu zu compilieren, ohne dass ich diese Units in einer anderen Umgebung compiliere?

Danke.

Das war der Fehler:
Ich habe eine Reihe von Routinen in andere Units verlagert. So wurde eine Unit auch erst in einer untergeordneten Unit verwendet. Dabei habe ich vergessen dise Unit aus der Uses herauszunehmen, die nicht mehr benötigt wurde. Dadurch liefen anscheinend einige Übersetzungsprozesse über Kreuz. Wenn der Compiler Threads zur Übersetzung der Units verwendet, kann es sein, dass eine Unit von 2 Threads gleichzeitig geöffnet oder die Objektdatei geschrieben wurden und ein Tread die Quelldatei blockiert hat. Das könnte erklären, dass ich die Unit nicht mehr mit Delphi öffnen konnte. Nachdem dieser "Kreuzverweis" behoben ist, arbeitet der Compiler wieder wie gewohnt. Diese Meldung scheint immer dann zu erscheinen, wenn der Compiler die Übersetzung am Ende einer Unit abbricht, egal aus welchem Grund.

Grüße von der sonnigen und warmen Nordsee

Peter

jaenicke - Fr 03.06.16 23:25

---

Der Compiler benutzt keine Threads. Im Gegenteil, es wird nicht einmal in die andere Richtung analysiert. Sprich jede Quelltextzeile wird nur einmal von vorne nach hinten geparst.

In anderen Sprachen wird gegebenenfalls auch in die andere Richtung geparst und dann weiter gemacht. Dadurch dauert der Kompiliervorgang bei diesen Sprachen aber länger, dafür sind Features wie LINQ möglich.

Das eine Unit in mehreren uses-klauseln steht, ist auch völlig normal.