How To Help Developing Lazarus/ja

From Lazarus wiki
Jump to navigationJump to search

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

メインページ - Lazarus Documentation日本語版 - 翻訳ノート - 日本語障害情報



  • 最新のFreePascal コンパイラ(FPC)もしくは最近のSVNバージョン(最も新しいもの)を入手して下さい。FPC を入手するには、FreePascal downloadを参照して下さい。
  • 次にSVNから最も新しいLazarusを入手する必要があります。これを入手するには、Getting Lazarus via SVNを参照して下さい。


最新の Lazarus を入手して開発の準備が整えました。けれども、“さて何から手を付けたらいいの?”という時に下記を参照してください。


もしLazarusについて個人的に特別な問題がなく、単に手助けしたいなら、バグリスト Bug Trackerの参照を推奨します。ここなら該当するバグを見つけてフィックスしたり、ハッキングする事ができます。 Lazarusチームは、1.0 に向けてで公開されたバグに優先順位を決めています。


Lazarus はより多くのドキュメントを必要としています。もしバグを修正する作業を望まないなら、ドキュメントを書くことによって貢献することも出来ます。まさにこのページは作業が進行中です。 利用価値のある情報を加えたり、間違いを見つけたら、このページのコンテンツを自由に改善してください。


オンラインIDEヘルプは、Wiki の一部として時間が経つにつれ作成されていきます。 最近、IDE ウィンドウに関する Lazarus IDE/ja ドキュメントの多数のページが追加されました。IDEの作業の際、ヘルプが必要になればF1キーを押してください。Wikiページからヘルプを参照することが出来ます(まだ作成されていなかったり、不完全だったりする場合があります)。適切な知識をお持ちであれば改善して下さい。


次のリンクを参照して下さい: Extending the IDE/ja, 1.0に向けて.

ウイジェットセット ("interfaces")

ウイジェットセット(WS) はターゲットから独立しているLCLコードの部分と、ターゲットOSのためのコードを生成するための"グルーコード (訳注:glue code オブザーバーパターンを実装したり、置換するコードのことか?)" です。 サポートされているそれぞれのOSでは、依存しているWSのユニットは C:\Lazarus\lcl\interfaces\. の中で見ることができます。


* テストするプロジェクトを作成します。(WSの変更のテストコードを含む小さいプログラムをつくります)
* 'Build Lazarus'と'Configure Build Lazarus' のためのキーボードショートカットを作ります。
  (IDEで Editor Options / Keymappingを選択);
 * LCLのみをビルドするように"Build Lazarus"を設定します。
  (IDEで Tools/Configure "Build Lazarus"を選択);
  * WSコードに変更を加えます。
  * Build Lazarus (IDEで Tools/Build Lazarus を選択
    - これはLCLと選択されたWSのみリビルドします。)
  * テスト用のプロジェクトをコンパイルします。
  * プログラムを実行してデバッグします。
 * "Build Lazarus"をすべてビルドするように再設定します。
   (IDEで再び Tools/Configure "Build Lazarus"を選択);
 * LazarusをビルドしてIDEをテストします。
* パッチを作って送ります


Creating A Patch/jaをみて、パッチを作成してください。 Lazarusの開発者にあなたのパッチを反映させる良い方法は、バグトラッカーに問題点のページをつくり、そこにパッチを添付することです。他の方法としては、Lazarusの開発者用のメーリングリストに投稿する方法があります。 へ送ってください。(タイトルに必ず "patch"をいれてください。また、最大40Kbまでです)

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 mirrors|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


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

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:

  • The Lazarus Mailing list (see Mailing list)
  • The #lazarus-ide IRC channel on

See also