Difference between revisions of "How To Help Developing Lazarus"

From Lazarus wiki
Jump to navigationJump to search
m (Note on "patch" in subject)
(27 intermediate revisions by 13 users not shown)
Line 3: Line 3:
 
== Prerequisites to developing Lazarus ==
 
== Prerequisites to developing Lazarus ==
 
There are two things to note:
 
There are two things to note:
* You should have the latest release of FreePascal compiler (FPC) or a recent SVN version (i.e. a later version) of it. For obtaining FPC, see [http://www.freepascal.org/download.html FreePascal download].
+
* You should have the latest release of Free Pascal compiler (FPC) or a recent SVN version (i.e. a later version) of it. For obtaining FPC, see [http://www.freepascal.org/download.var Free Pascal download].
 
* You '''must''' have the very latest Lazarus from SVN. For obtaining it, see [[Getting_Lazarus#Using_SVN|Getting Lazarus via SVN]].
 
* You '''must''' have the very latest Lazarus from SVN. For obtaining it, see [[Getting_Lazarus#Using_SVN|Getting Lazarus via SVN]].
  
Line 10: Line 10:
  
 
=== Known bugs ===
 
=== Known bugs ===
If you don't have any particular woes about Lazarus but just want to help, then I would recommend looking at the bug list [http://www.lazarus.freepascal.org/mantis/main_page.php Bug Tracker] find a bug that you think you can fix, and start hacking. The Lazarus team has prioritized the open bugs in the [[Road To 1.0]].
+
If you don't have any particular woes about Lazarus but just want to help, then I would recommend looking at the bug list [http://bugs.freepascal.org/set_project.php?project_id=1 Bug Tracker] find a bug that you think you can fix, and start hacking. Additional information on submitting bug reports and using the bug tracker can be found at [[How do I create a bug report]].
  
 
=== Documentation ===
 
=== Documentation ===
Line 20: Line 20:
  
 
=== IDE ===
 
=== IDE ===
See these links: [[Extending the IDE]], [[Road To 1.0]].  
+
See these link: [[Extending the IDE]].
  
 
=== Widgetsets ("interfaces") ===
 
=== Widgetsets ("interfaces") ===
  
A widgetset (WS) is the "glue code" between the LCL code parts that are independent of the target operating system and the target operating system itself. For each supported target OS, the corresponding WS units are to be found in one of the subdirectories under the C:\Lazarus\lcl\interfaces\.
+
A [[Widgetset|widgetset]] (WS) is the "glue code" between the LCL code parts that are independent of the target operating system and the target operating system itself. For each supported target OS, the corresponding WS units are to be found in one of the subdirectories under the C:\Lazarus\lcl\interfaces\.
  
 
Here is an outline of the steps one should follow, in order to improve a widgetset (description provided by Mattias Gärtner on the Lazarus mailing list on 2006-07-15). When making changes to a WS, it is not necessary to rebuild everything (Lazarus including the IDE), in order to test the efects of the changes. Proceed as follows:<br>
 
Here is an outline of the steps one should follow, in order to improve a widgetset (description provided by Mattias Gärtner on the Lazarus mailing list on 2006-07-15). When making changes to a WS, it is not necessary to rebuild everything (Lazarus including the IDE), in order to test the efects of the changes. Proceed as follows:<br>
Line 33: Line 33:
 
   (in IDE, go to Editor Options/Keymapping);
 
   (in IDE, go to Editor Options/Keymapping);
 
  <u>'''repeat'''</u>
 
  <u>'''repeat'''</u>
   * Configure "Build Lazarus" to only build the LCL  
+
   * build your application (this will re-build the WS you altered, and will re-build the LCL);
  (in IDE, go to Tools/Configure "Build Lazarus");
 
 
   <u>'''repeat'''</u>
 
   <u>'''repeat'''</u>
 
   * Make your improvement in the WS code;
 
   * Make your improvement in the WS code;
Line 49: Line 48:
  
 
== How to submit your changes? ==
 
== How to submit your changes? ==
You will need to make a "patch" (see [[Creating A Patch]]). The preferred way of submitting the patch to the Lazarus developers is to create an issue in the bug tracker and attach the patch to it. Alternatively you can send it to the mailing list (maximum size 40kB) or the mailbox for patches [mailto:patch@lazarus.dommelstein.net patch@lazarus.dommelstein.net] (put at least the word "patch" in the subject otherwise the mail will be rejected).
+
You will need to make a "patch" (see [[Creating A Patch]]). The preferred way of submitting the patch to the Lazarus developers is to create an issue in the bug tracker and attach the patch to it.
  
 
== Dealing with regressions ==
 
== Dealing with regressions ==
  
From time to time changes on the Lazarus source code might cause features which worked before stop working. In case there is no clue of what caused the break it may be useful to do a iteration method to determine exactly which revision caused the problem.
+
From time to time changes in the Lazarus source code might cause features which worked before to stop working. In a case where there is no clue as to what caused the break it may be useful to do an iteration method to determine exactly which revision caused the problem.
  
This process is simple, althougth somewhat time consuming:
+
This process is simple, although somewhat time consuming:
  
Suppose it works with rev 1000 and not with 5000. Then test with 3000. Testing requires updating the svn code, rebuilding lcl for desired widgetset, rebuilding a test application which uses the feature and testing this application. If it works, repeat with 3000 and 5000 as extremes. If not, use 1000 and 3000 as extremes.
+
Suppose it works with rev 1000 and not with 5000. Then test with 3000. Testing requires updating the svn code, rebuilding the LCL for the desired widgetset, rebuilding a test application which uses the feature and testing this application. If it works, repeat with 3000 and 5000 as extremes. If not, use 1000 and 3000 as extremes.
  
After some time you should be able to isolate which revision broke it. This information makes fixing the problem much easier, so we encourage people helping to develop Lazarus to try this process and post this information on bug reports in case they are regressions with no clear clue of what went wrong.
+
After some time you should be able to isolate which revision broke it. This information makes fixing the problem much easier, so we encourage people helping to develop Lazarus to try this process and post this information in bug reports in case there are any regressions with no clear clue of what went wrong.
  
To check to which data each revision correspondes one can use the [http://svn.freepascal.org/cgi-bin/viewvc.cgi/?root=lazarus Lazarus ViewCVS]. After the interval of revisions was reduced to a relative small number, like 25 or so, it may be quicker to check the revisions with ViewCVS and check which are possible canditates for the break, to speed up the final part.
+
To check to which data each revision corresponds, one can use the [http://svn.freepascal.org/cgi-bin/viewvc.cgi/?root=lazarus Lazarus svn browser (ViewVC)]. After the interval of revisions has been reduced to a relatively small number, like 25 or so, it may be quicker to check the revisions with ViewVC and check which are possible candidates for the break, to speed up the final part.
  
One can obtein a particular revision using the command:
+
One can obtain a particular revision using the command:
 
  svn update -r <revision number>
 
  svn update -r <revision number>
 +
 +
'''A word of caution.''' If you have a slow and unreliable internet connection (like modem dial-up or 3G) and limited bandwidth, then checking out various revisions from SubVersion is a slow and costly process. Every revision you checkout has to be downloaded from the internet.
 +
 +
This issue is completely eliminated if you use a [[git mirrors|Git mirror]] of Lazarus, because the whole repository history is local on you computer. So you can checkout any older revisions without needing an internet connection and checkouts are instant.
 +
 +
=== Automate searching for regression errors ===
 +
 +
==== SubVersion ====
 +
 +
Florian wrote a small Unix script which can help automate the process of finding a regression error. The script is called
 +
[http://svn.freepascal.org/cgi-bin/viewvc.cgi/scripts/florian/unix/searchrev?view=markup&root=fpcbuild searchrev].
 +
 +
There are command-line tools inspired by "git-bisect". A Unix shell script can be found in Debian-based Linux distributions as part of ''subversion-tools'' package. A Perl-based version can be found in some other Linux distributions (eg. SuSE, Fedora, CentOS) as ''svn-bisect'' package or [https://github.com/Infinoid/svn-bisect here].
 +
 +
==== Git mirrors ====
 +
 +
Git includes a command called ''bisect'' which helps with finding regression bugs. It also has built-in support for automated testing. You need to create a small testcase and let Git use that testcase to determine if a revision is buggy or not. So with the automated bisecting, regression bugs can be found in seconds. For more information on the ''git bisect'' command, see the [http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#using-bisect Git User Manual].
 +
 +
To download the Git mirror of the Lazarus repository, follow [http://github.com/graemeg/lazarus/tree/upstream this] link, or for more detailed instructions look here - [[git mirrors]].
  
 
== Need more help? ==
 
== Need more help? ==
  
 
If you have any question you can ask them on one of the following places:
 
If you have any question you can ask them on one of the following places:
* The Lazarus Mailing list (see [http://www.lazarus.freepascal.org/modules.php?op=modload&name=StaticPage&file=index&sURL=maill Mailing list])
+
* The Free Pascal mailing lists: [http://www.freepascal.org/maillist.var http://www.freepascal.org/maillist.var]
*The #lazarus-ide IRC channel on irc.freenode.net.
+
* The Lazarus Mailing lists [http://lists.lazarus.freepascal.org/mailman/listinfo http://lists.lazarus.freepascal.org/mailman/listinfo]
 +
* The [http://forum.lazarus.freepascal.org Lazarus Forum]
 +
* The [http://lazarus-dev.blogspot.de Lazarus Developer's blog]
 +
* The #lazarus-ide IRC channel on [http://www.lazarus.freepascal.org/index.php/page,9.html irc.freenode.net].
 +
* The [[FPC IRC channel]]
 +
 
 +
==See also==
 +
* [[Creating A Patch]] If you have modified the source code to implement a solution, this article helps you to add it to your bug report in the most efficient way, so that developers can add it to the main code as fast as possible
 +
* [[Database bug reporting]] Specific info and sample programs for database bugs
 +
* [[How do I create a bug report]] general information on submitting bugs, what should be covered in a bug report, and using the bug tracker.
 +
* [[Moderating the bug tracker]]
 +
* [[Lazarus Development Process]]
 +
 
 +
[[Category:Lazarus]]
 +
[[Category:Community]]
 +
[[Category:Debugging]]
 +
[[Category:FPC Issues]]

Revision as of 01:46, 5 September 2020

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

Prerequisites to developing Lazarus

There are two things to note:

  • You should have the latest release of Free Pascal compiler (FPC) or a recent SVN version (i.e. a later version) of it. For obtaining FPC, see Free Pascal download.
  • You must have the very latest Lazarus from SVN. For obtaining it, see Getting Lazarus via SVN.

Development areas

So now you have the latest version of Lazarus and wish to start improving it, but are asking yourself "where do I begin?" Well, that depends.

Known bugs

If you don't have any particular woes about Lazarus but just want to help, then I would recommend looking at the bug list Bug Tracker find a bug that you think you can fix, and start hacking. Additional information on submitting bug reports and using the bug tracker can be found at How do I create a bug report.

Documentation

Lazarus needs more documentation! If you don't want to fix a bug you can help by writing documentation. Even this page is a work in progress. If you have useful information to add, or if you see mistakes, please feel free to improve the contents of this page.

Look at Lazarus Documentation Editor and LCL Documentation Roadmap for some help on how to and a list of units to be documented.

The on-line IDE help is gradually being created as a part of the wiki. Recently a lot of stub pages of the Lazarus IDE documentation about the IDE windows have been added. When working in IDE, if you need help, press F1. You will be presented a help wiki page (possibly empty or incomplete). Improve it, if you have the relevant knowledge.

IDE

See these link: Extending the IDE.

Widgetsets ("interfaces")

A widgetset (WS) is the "glue code" between the LCL code parts that are independent of the target operating system and the target operating system itself. For each supported target OS, the corresponding WS units are to be found in one of the subdirectories under the C:\Lazarus\lcl\interfaces\.

Here is an outline of the steps one should follow, in order to improve a widgetset (description provided by Mattias Gärtner on the Lazarus mailing list on 2006-07-15). When making changes to a WS, it is not necessary to rebuild everything (Lazarus including the IDE), in order to test the efects of the changes. Proceed as follows:

* 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
 * build your application (this will re-build the WS you altered, and will re-build the LCL);
 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).

How to submit your changes?

You will need to make a "patch" (see Creating A Patch). The preferred way of submitting the patch to the Lazarus developers is to create an issue in the bug tracker and attach the patch to it.

Dealing with regressions

From time to time changes in the Lazarus source code might cause features which worked before to stop working. In a case where there is no clue as to what caused the break it may be useful to do an iteration method to determine exactly which revision caused the problem.

This process is simple, although somewhat time consuming:

Suppose it works with rev 1000 and not with 5000. Then test with 3000. Testing requires updating the svn code, rebuilding the LCL for the desired widgetset, rebuilding a test application which uses the feature and testing this application. If it works, repeat with 3000 and 5000 as extremes. If not, use 1000 and 3000 as extremes.

After some time you should be able to isolate which revision broke it. This information makes fixing the problem much easier, so we encourage people helping to develop Lazarus to try this process and post this information in bug reports in case there are any regressions with no clear clue of what went wrong.

To check to which data each revision corresponds, one can use the Lazarus svn browser (ViewVC). After the interval of revisions has been reduced to a relatively small number, like 25 or so, it may be quicker to check the revisions with ViewVC and check which are possible candidates for the break, to speed up the final part.

One can obtain a particular revision using the command:

svn update -r <revision number>

A word of caution. If you have a slow and unreliable internet connection (like modem dial-up or 3G) and limited bandwidth, then checking out various revisions from SubVersion is a slow and costly process. Every revision you checkout has to be downloaded from the internet.

This issue is completely eliminated if you use a Git mirror of Lazarus, because the whole repository history is local on you computer. So you can checkout any older revisions without needing an internet connection and checkouts are instant.

Automate searching for regression errors

SubVersion

Florian wrote a small Unix script which can help automate the process of finding a regression error. The script is called searchrev.

There are command-line tools inspired by "git-bisect". A Unix shell script can be found in Debian-based Linux distributions as part of subversion-tools package. A Perl-based version can be found in some other Linux distributions (eg. SuSE, Fedora, CentOS) as svn-bisect package or here.

Git mirrors

Git includes a command called bisect which helps with finding regression bugs. It also has built-in support for automated testing. You need to create a small testcase and let Git use that testcase to determine if a revision is buggy or not. So with the automated bisecting, regression bugs can be found in seconds. For more information on the git bisect command, see the Git User Manual.

To download the Git mirror of the Lazarus repository, follow this link, or for more detailed instructions look here - git mirrors.

Need more help?

If you have any question you can ask them on one of the following places:

See also