How To Help Developing Lazarus/de

│ Deutsch (de) │ English (en) │ español (es) │ Bahasa Indonesia (id) │ 日本語 (ja) │ português (pt) │ русский (ru) │

Voraussetzungen um an der Entwicklung von Lazarus mitzuarbeiten

Beachten Sie die folgenden beiden Punkte:

• Sie sollten die jeweils letzte offizielle Version des FreePascal Compilers (FPC) oder eine aktuelle SVN Version (d.h. eine Entwicklerversion mit höherer Build-Nr.) installiert haben. Um den FPC Compiler zu bekommen, siehe FreePascal download.
• Sie müssen ebenfalls über die allerneuesten Lazarus-Quelltexte von SVN verfügen. Um diese zu bekommen, siehe Getting Lazarus via SVN.

Entwicklungsbereiche

Sie haben die neueste Version von Lazarus. Sie möchten sie verbessern und fragen sich: "Wo kann ich beginnen?" Hier einige Anregungen:

Bekannte Fehler

Wenn Sie keine besonderen Probleme mit Lazarus haben, aber einfach helfen möchten, dann werfen Sie doch einen Blick auf die Fehlerliste Bug Tracker. Suchen Sie sich einen Bug, den Sie beheben können, und fangen Sie zu Hacken an. Das Lazarus Team hat die noch offenen Bugs nach Prioritäten aufgelistet in Road To 1.0.

Dokumentation

Lazarus muss besser dokumentiert werden! Falls Sie keine Fehler beheben wollen, können Sie vielleicht bei der Dokumentation mithelfen. Auch diese Seite ist in Bearbeitung. Falls Sie nützliche Informationen zum Hinzufügen haben, oder falls Sie Schreibfehler finden, dann zögern Sie nicht den Inhalt zu verbessern.

Schauen Sie nach bei LCL Documentation Roadmap für eine Liste der noch undokumentierten Units. Eine Hilfe wie's gemacht wird finden Sie unter Lazarus Documentation Editor.

Die Online-Hilfe der IDE entsteht schrittweise als Teil dieses Wikis. Dabei wurden der Dokumentation über die Lazarus IDE Fenster auch viele leere Seiten als vorläufige Platzhalter hinzugefügt. Wenn Sie in der IDE arbeiten und F1 drücken wird die Online-Hilfe aufgerufen. Dabei wird Ihnen eine Seite des Hilfe-Wikis angezeigt - möglicherweise ist sie aber leer oder unvollständig. Helfen Sie mit, sie zu verbessern, wenn Sie über das nötige Wissen dazu verfügen.

IDE

Siehe diese Links: Die IDE erweitern, Der Weg nach 1.0 Road To 1.0.

Widgetsets ("interfaces")

Ein Widgetset (WS) ist der "Kleber" zwischen den Teilen des LCL Codes, die unabhängig von einem Betriebssystem sind, und dem jeweiligen Ziel-Betriebssystem selbst. Für jedes unterstützte Ziel-Betriebssystem findet man die entsprechenden WS Units in einem der Unterverzeichnisse unter C:\Lazarus\lcl\interfaces\.

Hier ist eine Reihenfolge der Schritte die beim Verbessern eines Widgetsets zu beachten sind. (Diese Beschreibung wurde durch Mattias Gärtner von der Lazarus Mailing-Liste am 2006-07-15 geliefert.) Wenn Sie an einem WS Änderungen durchführen, ist es nicht notwendig alle Units (Lazarus inklusive der IDE) erneut zu kompilieren, um die Effekte Ihrer Änderungen zu testen. Gehen Sie so vor:

* Create your testbed project (a small program
  which should contain the testing code for your WS changes);
* Setup the keyboard shortcuts for 'Build Lazarus' and 'Configure Build Lazarus' 
  (in IDE, go to Editor Options/Keymapping);
repeat
 * Configure "Build Lazarus" to only build the LCL 
  (in IDE, go to Tools/Configure "Build Lazarus");
 repeat
  * Make your improvement in the WS code;
  * Build Lazarus (in IDE, go to Tools/Build Lazarus 
    - this only rebuilds the LCL, which rebuilds also the selected WS);
  * Now compile your testbed project;
  * Run and debug your program;
 until no errors are found in your change;
 * Reconfigure "Build Lazarus" to build all 
   (in IDE, go again to Tools/Configure "Build Lazarus");
 * Build Lazarus and test the IDE;
until no errors/degradation due to your changes are found in IDE;
* Create a patch and send it (see further below for details).

Wie reichen Sie ihre Änderungen ein?

Sie müssen dazu einen "Patch" erzeugen (siehe Creating A Patch). Der empfohlene Weg, um einen Patch an die Entwickler von Lazarus zu übermitteln ist der über den Bug Tracker. Erstellen Sie einen neuen Fehlereintrag (engl. "issue") und fügen Sie Ihren Patch als Anhang hinzu. Alternativ dazu können Sie ihn an die Mailing List übermitteln (maximale Größe 40kB) oder an die Mailbox für Patches patch@lazarus.dommelstein.net. (Schreiben Sie zumindest das Wort "patch" in das Feld 'Betreff' sonst wird Ihre Mail zurückgewiesen).

Der Umgang mit Rückfällen (engl. "regressions")

Von Zeit zu Zeit können die Änderungen am Lazarus Quellcode ungewollt bewirken, dass bisher zuverlässige Programmfunktionen ihr Verhalten ändern. Falls es keinen Hinweis darauf gibt, was diesen Bruch verursachte, könnte es hilfreich sein, mit einer Näherungsmethode exakt diejenige Lazarus-Revision zu bestimmen, die das Problem verursachte.

Dieser Vorgang ist einfach, aber auch etwas zeitraubend:

Angenommen ein Merkmal funktioniert mit rev 1000 aber nicht mit rev 5000. Dann testen Sie mit 3000. Diese Tests erfordern es, den svn code zu aktualisieren, die lcl für ein bestimmtes Widgetset neu zu erstellen, ebenso eine Testanwendung (die das Merkmal benutzt) neu zu erstellen und diese Anwendung ausführlich zu testen. Wenn das zufriedenstellend klappt, wiederhole das Verfahren mit den Revisionen 3000 und 5000. Falls nicht, nimm 1000 und 3000 als Schranken.

Nach einiger Zeit sollten Sie damit die Revision, die den Bruch verursachte, isolieren können. Diese Information erleichtert die Problembeseitigung sehr. Deshalb ermutigen wir alle, die an der Verbesserung von Lazarus mithelfen wollen, dieses Verfahren zu versuchen. Senden Sie uns die Informationen über Fehlerberichte die sich auf Rückfälle ohne klaren Hinweis auf die Problemursache beziehen.

Um zu prüfen, welche Daten mit einer Revision korrespondieren, können Sie den Lazarus svn browser (ViewVC) benutzen. Nachdem Sie das Intervall der Revisionen auf eine relativ kleine Anzahl (ungefähr 25) eingegrenzt haben, geht es vielleicht schneller, die Revisionen mit ViewVC zu untersuchen und so den möglichen Verursacher des Bruchs zu bestimmen.

Sie können eine bestimmte Revision erhalten, indem Sie folgenden Befehl benutzen:

svn update -r <revision number>

Ein Wort zur Warnung. Wenn Sie eine langsame oder unzuverlässige Internetverbindung (wie ein Modem oder 3G) und begrenzte Bandweite, dann ist das Checkout von verschiedenen Revisionen von SubVersion ein langsamer und teurer Vorgang. Jede auszucheckende Revision muss aus dem Internet heruntergeladen werden.

Dieses Problem entfällt vollständig, wenn Sie eine Git-Spiegelung von Lazarus verwenden, weil dann die vollständige History des Repositoriums lokal auf Ihrem Computer liegt. So können Sie beliebige ältere Revisionen auschecken ohne Internetverbindung und Checkouts passieren sofort.

Automatisieren der Suche nach Rückfallsfehlern

SubVersion

Florian schrieb ein kurzes Unix-Skript das hilft, die Suche nach Regressionsfehlern zu automatisieren. Das Skript heißt searchrev.

Git-Spiegelung

Git enthält einen Befehl namens bisect, der bei der Suche nach Regressionsfehlern hilft. Außerdem hat es eine eingebaute Unterstützung für das automatisierte Testen. Sie müssen einen kleinen Testfall erzeugen, den Git dazu benutzt, festzustellen, ob eine Revision fehlerhaft ist oder nicht. Mit dem automatisierten 'Bisecting', werden Regressionsfehler in Sekunden gefunden. Für weitere Informationen über den git bisect-Befehl, siehe das Git User Manual.

Sie haben noch Fragen?

Wenn Sie noch Fragen haben, dann können Sie diese an den folgenden Stellen loswerden:

• Die Lazarus Mailing Liste (siehe Mailing list)
• Der #lazarus-ide IRC Channel auf irc.freenode.net.

Siehe auch

• Lazarus Development Process