# How To Help Developing Lazarus

Deutsch (de) English (en) español (es) français (fr) 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. The Lazarus team has prioritized the open bugs in the Road To 1.0. 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.

### 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
* 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;
* 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 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.

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.

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.

To check to which data each revision corresponds one can use the Lazarus svn browser (ViewVC). 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 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 a 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.