Compiler-Schalter in Basis-Units

[Scurra]

Hallo zusammen,

wir verwenden bei uns DUnit für Unittests und möchten die Überprüfung von Memory-Leaks ermöglichen. Das haben wir in Delphi Seattle schon geschafft, weil die Units damals als Komponenten hinzugefügt wurden und nicht im Basis-Paket von Delphi enthalten war. Jetzt mit Delphi Rio sind die Units im Basis-Paket von Delphi enthalten, so dass wir es nicht mehr ohne Weiteres schaffen, die Überprüfung auf Memory-Leaks einzubauen.

Genauer gesagt haben wir folgendes Problem: Wir möchten FastMM als Memory-Manager benutzen und es gibt zahlreiche Seiten im Internet, die beschreiben, wie man den Memory-Manager integrieren kann. Ein Schritt dabei ist, dass man "FASTMM" als Compiler-Schalter setzen muss. Mit Delphi Rio haben wir nun aber das Problem, dass die Basis-Units nicht neu kompiliert werden. Somit wird der Compiler-Schalter nicht aktiv und die Integration gelingt nicht.

Als Work-Around haben wir die betroffene Units (GUITestRunner.pas und GUITestRunner.dfm) zu unseren Komponenten hinzugefügt, die wir über den Bibliothekspfad integrieren. Dadurch werden die Units von dort verwendet und auch neu kompiliert.

Gibt es eine schönere Lösung für das Problem als die betroffenen Units zu kopieren bzw. über den Bibliothekspfad hinzuzufügen? Kann man der IDE irgendwie mitteilen, dass die Basis-Units neu mit dem Compiler-Schalter kompiliert werden sollen?

[dummzeuch]

Zitat:

Zitat von Scurra (Beitrag 1450472)

Als Work-Around haben wir die betroffene Units (GUITestRunner.pas und GUITestRunner.dfm) zu unseren Komponenten hinzugefügt, die wir über den Bibliothekspfad integrieren. Dadurch werden die Units von dort verwendet und auch neu kompiliert.

Gibt es eine schönere Lösung für das Problem als die betroffenen Units zu kopieren bzw. über den Bibliothekspfad hinzuzufügen? Kann man der IDE irgendwie mitteilen, dass die Basis-Units neu mit dem Compiler-Schalter kompiliert werden sollen?

Einfache Antwort: Nein.

[Scurra]

Zitat:

Zitat von dummzeuch (Beitrag 1450479)

Einfache Antwort: Nein.

Schade. Aber danke für die Antwort!

[Uwe Raabe]

Allerdings steht in der readme-fastmm.txt auch:

Zitat:

Delphi / BDS 2006 and later already include FastMM support for leak reporting on shutdown and so does not require the conditional definitions mentioned below for earlier versions of Delphi.

[Stevie]

Für Memoryleak Detection in DUnit/DUnitX Tests empfehle ich die Benutzung von LeakCheck.

[hoika]

Hallo,
also ich binde die FastMM4 als erste Unit im Projekt ein.
Dann noch die INC-Datei konfigurieren und fertig.

Außerdem: Wie weiter oben schon steht, FastMM4 ist seit x Delphi-Versionen
in einer abgespeckten Version bereits im Delphi drin.
ReportMemoryLeaksOnShutDown:=True kann also direkt in der DPR geschrieben werden.

[Scurra]

Zitat:

Zitat von Uwe Raabe (Beitrag 1450488)

Allerdings steht in der readme-fastmm.txt auch:

Zitat:

Delphi / BDS 2006 and later already include FastMM support for leak reporting on shutdown and so does not require the conditional definitions mentioned below for earlier versions of Delphi.

Nun ja, im GUITestRunner von DUnit gibt es Code mit "{$IFDEF FASTMM}", der nicht ausgeführt wird, weil der Compiler-Schalter nicht gesetzt ist. Das führt dazu, dass man die Checkbox für die Memory-Leaks nicht setzen kann.

Wir haben die Unit inzwischen explizit zum Projekt hinzugefügt, damit es neu kompiliert wird, man kann nun die Checkbox auch setzen, aber die Prüfung scheint trotzdem nicht stattzufinden bzw. es wird kein Memory-Leak erkannt, obwohl wir extra welche eingebaut haben für unseren Test.

Zitat:

Für Memoryleak Detection in DUnit/DUnitX Tests empfehle ich die Benutzung von LeakCheck.

Danke, das werden wir uns mal anschauen.

Zitat:

ReportMemoryLeaksOnShutDown:=True kann also direkt in der DPR geschrieben werden.

Soweit ich weiß, führt ReportMemoryLeaksOnShutDown dazu, dass ein Fenster angezeigt wird mit den Memory-Leaks. Das ist sicherlich geeignet, wenn man die Tests manuell startet. Für einen automatischen Build-Prozess ist das leider nicht geeignet.

[Scurra]

Zitat:

Für Memoryleak Detection in DUnit/DUnitX Tests empfehle ich die Benutzung von LeakCheck.

Ich habe mir das mal angeschaut. Das scheint leider nicht mehr weiter entwickelt zu werden (der letzte angegebene Support ist für Delphi XE7 und der letzte Commit war 2017). Deshalb haben wir uns dazu entschieden, ohne Leak-Checks in Unit tests auszukommen. Notfalls müssen wir ReportMemoryLeaksOnShutdown nach der Implementierung der Tests auskommen.

Trotzdem danke für den Hinweis auf LeakCheck.

[hoika]

Hallo,

Zitat:

Soweit ich weiß, führt ReportMemoryLeaksOnShutDown dazu, dass ein Fenster angezeigt wird mit den Memory-Leaks. Das ist sicherlich geeignet, wenn man die Tests manuell startet. Für einen automatischen Build-Prozess ist das leider nicht geeignet.

Das Fenster müsste ausschaltbar sein, dann wird nur eine Textdatei mit den Leaks erzeugt.

[Stevie]

Zitat:

Zitat von Scurra (Beitrag 1451544)

Zitat:

Für Memoryleak Detection in DUnit/DUnitX Tests empfehle ich die Benutzung von LeakCheck.

Ich habe mir das mal angeschaut. Das scheint leider nicht mehr weiter entwickelt zu werden (der letzte angegebene Support ist für Delphi XE7 und der letzte Commit war 2017). Deshalb haben wir uns dazu entschieden, ohne Leak-Checks in Unit tests auszukommen.

Eure Entscheidung, aber lass dir gesagt sein, dass ihr auf ein wertvolles Werkzeug verzichtet. Wir benutzen LeakCheck mit 10.1 ohne Probleme in unseren Unit- und Integrationstests und auch bei der Spring4D Entwicklung setze ich es mit der neuesten Delphiversion und auch auf anderen Betriebssystemen als Windows ein. Grad wenn man mal nen Leak hat, was durchaus nen ganzer Batzen an Objekten sein kann, ist der Dependency Graph, den Leakcheck bauen kann, unerlässlich, um fix die Ursache zu finden (oder gar zu sehen, dass man eine zirkuläre Referenz hat, wo sich Dinge gegenseitig am Leben halten).