Unofficial OpenOffice Hacker's guide

English | Japanese | German

# 非公認 OpenOffice ハッカーズガイド

OpenOffice.org (OO.o)をビルドしたり、ハックしたりするには 本当に長ーーい坂道を登ることが必要とされる。できることならこの 文章が学習曲線を多少立ち上げの角度を上げて、またより急激に させて、あなたの助けとなる歩く杖でありたい。《訳注：この部分特に訂正を乞う》

この文章は時間を節約するために、あなたが現在使われてる妥当なバージョンのLinuxを使っていることを仮定している。真のハッカーは、Free softwareを使います、また非フリーな要素について読んでいる時間はありません。

我々の狙いは、少なくとも以下の質問に答えることです。

- どうやってOO.oをビルドするのか?
- どうやって、開発の輪に入っていけば良いのか?
- どうやって、デバッグすれば良いのか?
- どうやって、パッチを送れば良いのか?

## 0. 目次

- 1. OO.oを入手する
- 2. OO.oをビルドする
- 3. OO.oをイントールする
- 4. OO.oを実行する
- 5. OO.oをハックする
- 6. OO.oをデバッグする
- 7. パッチを配布するには
- 8. その他、TIPS
- 9. 有用なリンク集
- 10. IFAQ
- 11. 我々と一緒にやるには

この(一連の)作業の詳細については 詳細ビルド・ガイドで話し合いましょう。. 我々は、本当に一生懸命に働いて、単なる死すべき運命のプログラマーのための実行可能なプロセスを作りあげました。そして、その簡単な説明を以下に行います。

## 1. OO.oを入手する

複数の優れたパッチセットが存在する、たくさんの競合する バージョンといくつかの選ばれたブランチのOO.oがあります。 私は、CVSスナップショットからのビルドを勧めます。それらは ビルドできることが知られ、パッチセットが適用できることが知られて います。さあ、ソースをこのように取得してみましょう：

        export CVSROOT=':pserver:anonymous@anoncvs.gnome.org:/cvs/gnome'
        cvs login
        cvs -z3 checkout -dP openoffice

これらは、OO.oのビルドを行う一式のコピーをあなたの(コンピュータのハードディスクへ)落し込みます。もし、CVSがあなたを驚かせたのなら、最近のパッケージ化されたバージョンもここから取得できます。

注記: あなたは、OO.oをビルドするのに、余分なスペー スとして4Gバイト以上の領域が必要だ。そして、ビルドするためのソース コードをダウンロードするのに200Mバイト以上の領域が必要だ。

## 2. OO.oをビルドする

### 2.1. configure

ビルドの作業は、かなり複雑である。あなたは今コマンド(《訳注》コマンドライ ン?)を選択するのだが、とはいえ(ビルドが複雑であることと、コマンドラインを 選択することが)は、本当の致命傷にはならない。

          ./autogen.sh # the CVS version
          ./configure  # the packaged version

これは、あなたがビルドしたいのは、スナップショット・ブランチである という推測である。もし、あなたが別のアイディアとしては、 --with-tagオプション(例:

    --with-tag=OOO_1_0_3

)をこれまで のブランチと同じように使うことでしょう。

### 2.2 ダウンロード

あなたが自分のシステムをOO.oをビルドできるように全てのパッケージ (mozillaや、最近のlibartなどなど)をアップグレードするまでには、あ なたは(OO.oの)ソースをダウンロードすることができる所に、ほぼ来てい る。それを行うには、configureを成功させた後に、単に

    ./download

と入力して、待てば良い。

### make

ここは、ちょっと面倒です。-

    make

と入力して、忘れずに Enterキーを押しましょう。完全なるログ出力が欲しいときには、

    make 2>&1 | tee /tmp/log

とやってみてはどう?

## 3. OO.oをインストールする

完璧にビルドした結果、

    build/$TAG/instsetoo/unxlngi4.pro/01/normal/

などの場所 でインストール用セットが完璧にzipで固められた《訳注:そうなの?》 状態になっています。あなたは、手動でセットアッププログラムを動かし てインストールすることができます。または

    sudo make
          install

を実行して あなたのためにシステムプレフィックス設定 された状態で、OO.oがインストールされます。

インストールされたら、単にOO.oを再実行することで、サブディレクトリ のソースを再コンパイルした結果、イントールされたイメージから直接ビ ルドツリーからリンクすることによりハックしているような気分を得るこ とができる。これにより、ビルドとテストのサイクルがほんの数十秒で可 能になります。それを行うには、例:

    linkoo
          /usr/lib/ooo-1.0.3 /opt/openoffice/build/RC3_030729

である

## 4. OO.oを実行する

linkooを実行するときにプレフィックスを付けたことに、不思議に思った と思う；そして

    cd program; . ./ooenv

を実行したことも。この 手順がシェルがOO.oを直接実行するための環境設定(セットアップ)になり ます。その後、

    soffice.bin

を実行します。これは、soffice を実行したり、ラッパスクリプト経由で実行するよりも、

    gdb
          soffice.bin

のようにデバッガをアタッチするのが大変容易で、良 い方法です。

注:

    ./soffice.bin

は不可解な理由で完璧に 動作に失敗するは使わないでください。

注: あなたは、oooのラッパを噛ませたOO.oを走らせる 前に、~/.sversionrcのようなものをを最初に正しく設定するか、または soffice.binを走らせて、GUI設定ツールを起動させます。これは、あなた が始める前に一度だけ

    oowriter

を実行しておくのです。

## 5. OO.oをハックする

### 5.0. 最初のハック

では - われわれは、OO.oをビルドして実行しました。そして、わたし たちは、あなたのマシンの上でOO.oをハックすることが実際に可能である 、とわたしたち自身が証明することを望んでいます。では、新しいターミ ナルの中で、以下のコマンドを実行してみてください:

          cd build/$TAG
          . ./LinuxIntelEnv.Set.sh
          cd vcl

いま、vcl/source/window/toolbox.cxxの中をハックしています; 私は、例えば、ToolBox::PaintのImplDrawItemの前に

    if
          (i%2)

を追加してみて、保存します。

まだ vcl/の中にいますか? はい。それから、'build debug=true'と入力 して、文字列がスクロールして、止るのを待ちます。(5秒ぐらい?)。では、

    soffice -writer

を再実行します。あなたは、効果が出るのか を注意しておかねばなりません。

注:毎日ハックしているあなたは、ソースツリーの中で' build'を実行したいと思うでしょう。やってはいけません

    openoffice/

ディレクトリの一番上のレベルでmakeを実行する ことは。あなたは、十中八九、自分が行った変更をゴミ箱行きにすること になり、(あなたを)意気消沈させます。 これは、再配置するビルドを行う手助けとして ここを見て、どこか

    build/OOO_1_1_0

の他のコピー範囲外でありつづけるのは納得 できる。《訳注:ここも意味不明です。》

### 5.1. すばらしいマニュアルを読む

C++の力を使うことにより、なお一層簡単に(または、暗黙的に)(よけいな ことをして)自分から災いを招くような能力が得られます。参考Holub, Rules for C and C++ programming, McGraw-Hill, 95《訳注:amazon には原著の在庫はなかった。未訳?》

闘いに臨む最高の方法は、OpenOfficeコーディング・ガイドライン ここを読むことであり、c'tor / d'torがコンストラクタ/デストラク タの略であるとたやすく間違えてしまうことである。

### 5.2. パッチを送る

bugzilla《訳注:問題解決システム》の中にモジュールのパッチが存在す ることはまれである。以下のように試して、作業してみるのが簡単である

    cvs status <somefile> | head

これにより'Repository Revision:'の行、パス、そして2つ目の部分がプ ロジェクト名を表わします。

### 5.3 インストーラをハックする

インストーライメージは(実行可能な)テンポラリ・セットアップ・イメー ジ`/tmp/sv001.tmp`を削除するときには、それを停止させておく 必要がある。そうするには、セットアップ/インストールに- dontdeletetempオプションを付けて実行する。《訳注:ここも意味不明な 日本語になっている》

### 5.4. 別の部分をハックする

インストールが動作すると、ハックを追加する最も良い方法は、 `program/libfoo641li.so`にシンボリックリンクをあな たがビルドしたバージョンに張ることです — ありそうなのは、 `foo/unxlngi4.pro/lib/`ですが。その後、(オフィス) スイートを実行すると、あなたの行った変更が入っているはずです。

例として、あなたが'sal'(System Abstraction Layerの略)をハックした いとすると、あなたは、/opt/OOInstallからOOO_STABLE_1をインストール したとすると、あなたはこのようにする必要がある。

    cd /opt/OOInstall/program
    mkdir backup
    mv libsal.so.3.0.1 backup
    ln -s /opt/OpenOffice/OOO_STABLE_1/sal/unxlngi4.pro/lib/libsal.so.3.0.1 .

### 5.5. D' make (man)を理解する

システムをビルドしている間、似たような他のシステムがあります。これ は、また多分ちょっとだけ異なります。概略は、それぞれモジュールを ビルドしていたものであり、それから結果が派生した solverである。おのおののモジュールは、solverの中のヘッダーに対 してビルドされる。なので、このような少し複雑なことになっている。

- ビルド — このperlスクリプト solenv/bin/build.plは、最初にビルドする必要がある全ての モジュールを確実にprj/build.lstが 関連して使用されるようにする。ビルド後のun-windsな内部モジュー ルの依存関係、また、それぞれのモジュールがディレクトリの変更、 dmake の組のビルド《訳注:ここも意味不明》
- deliver — この perl スクリプト (solenv/bin/deliver.pl)は、ヘッダやライブラリなどなどprj/d.lst形式でsolverを使ってをイン ストールします。決定的なことは、deliverが、モジュールディレク トリの中にある solver と同じ場所にインストールされたいかなるファ イルの日付タイムスタンプを保証することです。この、(特にヘッダー は)他のモジュールの再ビルドの引き金を引く流れに依存関係がない ことを保証する。 deliver — this perl script solenv/bin/deliver.pl installs headers, and libraries (etc.) into the solver, as informed by prj/d.lst. Crucially deliver ensures that the date stamp on any file that is installed to the solver is the same as that in the module's directory. This ensures, that (particularly for headers) that there is no dependency cascade triggering re-builds in other modules.

#### 5.5.1 標準的なディレクトリ

これらは、OO.oを作り上げるモジュールの中の標準的にある様々なディレ クトリやファイルで、これらが、その中でより有益なものです。 There are various standard directories and files in most of the modules that make up OO.o, here are some of the more useful:

- prj
  - build.lst — このディレクトリリストは、'^#'の コメントを許し、このリストの並び順は、重要ではない。詳細を見よ。これはビルド 作業が作成する。 build.lst — this lists directories to be made, '^#' comments are allowed, the order of the list is immaterial see detail, it is dictates build's operation.
  - d.lst — これはdeliverプロセスを記述す る。詳細を見よ d.lst — this file describes the deliver process, see detail.
- util — 一般的なutilディレクトリは、GUIリソース・ ファイルなどを作成したり、システム・ライブラリに依存関係を追加し たり、それぞれのサブ・モジュールをサブ・ライブラリをまとめて、一 つの大きなライブラリにまとめる役目を負っている。 全ての作業は、makefile.mkに記述されている。これは、たい てい、このプロジェクト《訳注:ビルド作業のプロジェクト》が作成 する最後のディレクトリである。 util — typically the util directory is charged with glueing together the sub-libraries for each sub-module into a single large library, adding system library dependencies, building GUI resource files etc. All the work is described in makefile.mk, this is usually the last directory to be built in a project.
- inc — 公開ヘッダは通常、'inc' ディレクトリに分離 される。これらは、'deliver'フェーズに(prj/d.lstを使って) solverへインストールされます。 inc — public headers are typically separated into an 'inc' directory, these will be installed into the solver by the 'deliver' phase (using prj/d.lst)

これからもまた、興味深い(深くない)ファイルです: There are also various file types that are (or are not) interesting:

- makefile.rc — これからはすべて、冗長であり、無視 しても大丈夫です。 makefile.rc — these are ~all redundant, and can safely be ignored.
- makefile.mk — これらは、ソースディレクトリ毎に使 われる'dmake'ファイルとの(対照によって示される)差異である。 makefile.mk — these in contrast are the 'dmake' files, that are used to build each source directory.

#### 5.5.2 build.lst

ちょっと見には、build.lst は、おっかないように見える: On first view build.lst looks scary:

    vc      vcl : nas freetype psprint rsc sot ucbhelper unotools sysui NULL
    vc      vcl                      usr1   -       all     vc_mkout NULL
    vc      vcl\source\unotypes      nmake  -       all     vc_unot NULL
    vc      vcl\source\glyphs        nmake  -       all     vc_glyphs vc_unot NULL

そう。我々は、実際はパッと見ほど奇妙でない、ここで何が行なわれているのか をやってみて、解明する必要がある。リストの最初は 'NULL'文字で終端 されている各行は、見当外れの便法により接頭辞がついている。 so we need to try and un-pack what's going on here, which is in fact not as odd as it might seem at first glance. Firstly lists are terminated by the 'NULL' string. Every line is prefixed by a shortcut which is irrelevant.

- 最初の有効行は、':'を含んでいます。これは、このプロジェクト (vcl)が他のモジュール'nas','freetype','psprint'などに依存して いる事実を記述している。これはプロジェクト間の依存関係です。 First active line contains a ':', this describes the fact that this project (vcl) depends on these other modules 'nas', 'freetype', 'psprint' etc. to be built first. This is for inter-project dependencies.
- その後の、'usr1'という冗長行 [ 楽しみのため? ]が、実際には、 魔法の文字列である'nmake'を含んでいる後の部分が正しいのです。 Then we have a redundant line 'usr1' [ for fun ? ], in fact only lines containing the magic string 'nmake' are valid after this.
- その次の行は、内部のプロジェクト・ディレクトリ記述します。こ んな風に: The next lines describe internal project directory dependencies and look like:

      [shortcut] [path to dir to build] nmake - [flags] [unique-name] [deps...] NULL
      vc           vcl\source\glyphs    nmake -   all     vc_glyphs   vc_unot   NULL

  ショートカット(shortcut) 使いません; フラグ (flags) どのプラットホームでビルドするかを決定します;通常 は single char《訳注:wide char(日本などの多バイトを表わす)の 反対の意味?》のプラットホーム・コードです:'dnpum' 'u'は、Unix です。より良いシステムは、より多くのいろんなものを生成する' all'フラグになります。

  unique-name これは、マジック名で内部の依存関係を記述す る別の行で使われます。deps... このファイルがある、いか なる名前のディレクトリであっても、これは最初にビルドされねば なりません。 shortcut is not used; flags determines which platforms this builds on; usually single char platform codes: 'dnpum' 'u' being Unix. The higher up the system, the more stuff is flagged 'all'.

  unique-name this is a magic name, used by other lines to describe an internal dependency. deps... any number of names of other directories in this file, that must be built before this one.

そう、わたしたちは、vcl\source\unotypes (vc_unot) が vcl\source\glyphs (vc_glyphs)よりも前にビルドされることを知っ ています。リストの並び順は重要でないのと、単純な順序リストの代わり に、わたしたちはより複雑な内部用依存関係(保持)システムを持っている ということを理解することが重要です — この比較により多 くの他のmakeシステムとの対比になります。 So we see in the vcl case that vcl\source\unotypes (vc_unot) has to be built before vcl\source\glyphs (vc_glyphs). It is important to understand that the order of the list is ~immaterial, and instead of a simple ordered list, we have a more complex internal dependency system — this contrasts with most other make systems.

ここに も、またドキュメントがあります。 There is also documentation here on it.

#### 5.5.3 d.lst

build.lstは、build.lstをinc/<module>/build.lstへコ ピーするような、いくつかのデフォルトのアクションを省略しており、 d.lstの文法は、build.lstよりも解りやすいです。

The syntax of d.lst is more comprehensible than build.lst, it omits some default actions, such as copying build.lst into inc/<module>/build.lst.

行の形式: A line is of the form:

    [action]: [arguments]
    mkdir:    %_DEST%\inc%_EXT%\external

    [action]: [arguments]
    mkdir:    %_DEST%\inc%_EXT%\external

どこかでもし、'[action]:'を省略したら、その動作のデフォルトは 'コ ピー' 動作です。 代表的な動作は copy, mkdir, touch, hedabu,dos and linklib.

です。, where if '[action]:' is omitted, it defaults to the 'copy' action. Typical actions are copy, mkdir, touch, hedabu, dos and linklib.

where if '[action]:' is omitted, it defaults to the 'copy' action. Typical actions are copy, mkdir, touch, hedabu, dos and linklib.

'hedabu'動作は特に興味深い, inasmuch は、見掛け上インストール時に ヘッダーを見掛け上再整形して小さくする(または、コピー動作のように ふるまう)

The 'hedabu' action is particularly interesting, inasmuch that it cosmetically re-formats the header to shrink it on install (otherwise it's much like the copy action).

動作中は, 様々なマクロ変数がこのように展開される:

- %__SRC% — 配布ディレクトリ名 例えば、unxlngi4.pro
- %_DEST% — solverへの絶対パス 例えば、/opt/OpenOffice/OOO_STABLE_1/solver/641/unxlngi4.pro
- %_EXT% — (通常はない) way of having マイナー更新 例えば、 641.1です。通常サブディレクトリのバージョン名として使われます。

一般的なその他は、もし実際にあなたがルールを追加する必要があるとす る(参考：暗黙のディレクトリコピー)と、それは下記のような形式になる だろう。

    ..\%__SRC%\inc\sal\*.h %_DEST%\inc%_EXT%\sal\*.h

注意せよ. 相対パスは、'proj/'ディレクトリへの相対(パス)です During the action, various macro variables are expanded some of which are:

- %__SRC% — distribution directory name eg. unxlngi4.pro
- %_DEST% — absolute path into solver eg. /opt/OpenOffice/OOO_STABLE_1/solver/641/unxlngi4.pro
- %_EXT% — (unusual) way of having minor updates eg. 641.1, typically used to version every base sub-directory.

Typically then, if indeed you need to add a rule (cf. implicit directory copies), it will be of the form:

    ..\%__SRC%\inc\sal\*.h %_DEST%\inc%_EXT%\sal\*.h

NB. relative paths are relative to the 'prj/' directory.

### 5.6 ファースト イテレーション(繰り返し)

### 5.6 fast iteration

これらは、開発サイクルくりかえす、多数の方法です。最上の方法は、 linkooをつかって、 インストールセットから あなたのビルドツリーへライブラリをシンボリッ クリンクを張ることです。そのあと、あなたは単にサブディレクトリを再 ビルドすることができます。例えば、

    vcl

は、

    build

により実行され、soffice.binを再び実行します。

There are lots of ways to go round a devel iteration; the best way is to use linkoo to symlink the libraries from the install set directly into your build tree. Then you can simply re-build a sub-directory eg.

    vcl

by running

    build

and re-run soffice.bin.

### 5.7 どうしたら、`char *`が使えますで しょうか?

### 5.7 Can I get a `char *`, please?

やっと、かろうじて。 OO.o は少なくとも4つの文字列ラッパーがありま す。

Just barely. OO.o has at least four string wrappers:

- `rtl_String` — sal/inc/rtl/string.h
  "通常は" 文字列およびレファレンスカウンター. `rtlstring->buffer` は有用です。そのままで `rtlstring->length`. この文字列は、すでに、特定の キャラクター集合に変換されています; 参照 sal/inc/rtl/textenc.h — 興味深いケースは、 `RTL_TEXTENCODING_UTF8` と、ことによると `RTL_TEXTENCODING_ASCII_US` は、真のラッダイト運動家のためである。 `rtlstring->buffer`は、あなたの最愛の`char *` `rtlstring->buffer` と同じように自由に扱えると感じ るでしょう。

  `rtl_String` — sal/inc/rtl/string.h
  "Normal" string plus reference counting. `rtlstring->buffer` is useful, as is `rtlstring->length`. This string has already been converted to a particular character set; see sal/inc/rtl/textenc.h — the only interesting cases are `RTL_TEXTENCODING_UTF8` and perhaps `RTL_TEXTENCODING_ASCII_US` for real luddites. Feel free to treat `rtlstring->buffer` as your beloved `char *`.

- `OString` — sal/inc/rtl/string.hxx
  は、単に rtl_String を `class`に ラッピングしていま す。あなたは、`ostring.pData`をrtl_String(パブリッ ク属性だ)を取得するに使うことができる。`OString` は、 もしあなたが必要とするなら、妥当で使いやすいメソッドです。

  `OString` — sal/inc/rtl/string.hxx
  Simply a rtl_String wrapped inside a `class`; you can use `ostring.pData` to get at the rtl_String (it's public). `OString` has reasonably useful methods for if you need them.

- `rtl_uString` — sal/inc/rtl/ustring.h
  "通常は" ユニコード文字列, rtl_Stringと同様で、参照カウンタも 同様である。しかしながら、この型は、常にUCS-2エンコードである。 思うにJavaの疑わしき選択への互換性のためのエンコードである

  `rtl_uString` — sal/inc/rtl/ustring.h
  "Normal" Unicode string, similar to rtl_String, and refcounted as well. However, this one always comes in UCS-2 encoding, presumably to be compatible with Java's questionable choices.

- `OUString` — sal/inc/rtl/ustring.hxx
  rtl_uStringは、`class`の中にラップされている. これは、OO.oのコードの大部分がこの文字列をこの型に入れている。

  `OUString` — sal/inc/rtl/ustring.hxx
  An rtl_uString wrapped inside a `class`. This is what most of the OO.o code uses to pass strings around.

真の男は、UTF-8エンコード文字列を`char *`で扱う。 'printf'のような、`OUString`からchar *を導き出すことが 必要ないかなるシステムAPIは、下記のように使用する:

Since real men use `char *` strings encoded in UTF-8; to use any system API such as 'printf' you need to extract a char * from a `OUString` use this:

    static char *
    gimme_utf8_please (const rtl::OUString &oustring)
    {
    	rtl::OString ostring;

    	ostring = ::rtl::OUStringToOString (oustring, RTL_TEXTENCODING_UTF8);
            return strdup (ostring.pData->buffer);
    }

逆の場合:

And the reverse:

    static rtl::OUString
    complicate_things_into_ucs2_please (const char *utf8_string)
    {
    	rtl::OString ostring;

            ostring = rtl::OString (utf8_string);
    	return rtl::OStringToOUString (ostring, RTL_TEXTENCODING_UTF8);
    }

#### 5.7.1. 落とし穴

#### 5.7.1. Pitfalls

重要 rtl_String や rtl_uString APIは、かなり不細工だ. 新しい文字列を作成するこれらの機能は、あな たが、下記のように、これら(rtl_Stringやrtl_uString)を呼出す前に文字 列にNULLを入れて、元の値を設定しなくては*ならない*;

Important The rtl_String and rtl_uString APIs are massively clunky. For the functions that create new strings, you have to set the original value of the string to NULL before calling them, like this:

    rtl_String *str;

    str = NULL; /* If you don't do this, your program will crash */
    rtl_string_newFromStr (&str, "hello world");

    rtl_uString *ustr;
    ustr = NULL; /* Same as above */
    rtl_uString_newFromAscii (&str, "hello Unicode world");

これらの関数が、もしそれらがNULLでなければ文字列をrelease()する関 数の変種を最初に呼出す試みする。というのが理由である。— メモリリークを避ける原則として、あなたは文字列を再設定した方が良い。 ;実際あなたの人生を難しくしている(単におおげさにいっているだけで、 ややこしくしているぐらいで良いか)

This is because those functions attempt to first call the release() variants for the strings if they are not NULL — in principle to avoid memory leaks should you try to re-assign strings; in practice to make your life hard.

#### 5.7.2. GDBから文字列を調べる

#### 5.7.2. Examining strings from GDB

我々は既にOO.oが粗末な`char *`を使っていないことを見て きた。もしあなたがコードを書くことは十分だと考えているなら、あなた は、OO.oをデバッグしなければならなくなるまで待たなくてはならない。 文字列をどのように取りだすかがこの節です:

We have already seen that OO.o does not use humble `char *` strings. If you thought this was painful enough when writing code, wait until you have to debug it. Here's how to get at your strings:

- rtl_String: その中を見よ
- rtl_String: just poke at it
- 文字列: — 注, decl'は'UniString'マクロを使って、 tools/inc/string.hxxの読み手を混乱させます。 FIXME: UniStringsのマクロをきちんと出力する あなたがたぶん望むように出力できるような形式に機械的に変換する:

      fprintf (stderr, "String is '%s'\n",
               (::rtl::OString (MyString.GetBuffer (),
      	                  MyString.Len(),
      			  RTL_TEXTENCODING_UTF8)).getStr());

  もちろん、stdio.hとrtl/string.hxxが欠けているならインクルードする 必要があります。
- String: — note, the decl' of this uses the macro 'UniString' to confuse readers of tools/inc/string.hxx, FIXME: need a macro to dump UniStrings nicely To convert programmatically to something you can print you probably want:

      fprintf (stderr, "String is '%s'\n",
               (::rtl::OString (MyString.GetBuffer (),
      	                  MyString.Len(),
      			  RTL_TEXTENCODING_UTF8)).getStr());

  of course, you also need to include stdio.h and rtl/string.hxx if they are missing.
- OString: gdbのコマンドプロンプトでp str->pDataと入れよ
- OString: p str->pData
- OUString, rtl_uString: あなたの~/.gdbinitに下記の記述が必要で す:

      define prtls
      	set $poui = 0

      	echo Building '$arg0'...
      	while $poui < $arg0->length
      		set $pouc = $arg0->buffer [$poui++]
      		if $pouc < 32
      			printf "\\0%o", $pouc
      		else
      			if $pouc <= 127
      				printf "%c", $pouc
      			else
      				printf "\\0%o", $pouc
      			end
      		end
      	end
      	echo \n
      end

      define pou
      	prtls $arg0->pData
      end

  注. 理解できない理由によりgdbは、2回目に単一の文字列を表示します 'rtl_uString *'のためにprtls と'OUString *'のために pouを使 います。OUStringはあなたが望むように機械的に出力します:

      ::rtl::OString tmpStr = OUStringToOString (MyOUString, RTL_TEXTENCODING_UTF8);
      fprintf (stderr, "String is '%s'\n", tmpStr.getStr());

- OUString, rtl_uString: you're going to need this in your ~/.gdbinit:

      define prtls
      	set $poui = 0

      	echo Building '$arg0'...
      	while $poui < $arg0->length
      		set $pouc = $arg0->buffer [$poui++]
      		if $pouc < 32
      			printf "\\0%o", $pouc
      		else
      			if $pouc <= 127
      				printf "%c", $pouc
      			else
      				printf "\\0%o", $pouc
      			end
      		end
      	end
      	echo \n
      end

      define pou
      	prtls $arg0->pData
      end

  NB. for reasons unknown gdb will take ~seconds to print a single string. Use prtls for 'rtl_uString *' and pou for 'OUString *'. To programatically print a OUString you need:

      ::rtl::OString tmpStr = OUStringToOString (MyOUString, RTL_TEXTENCODING_UTF8);
      fprintf (stderr, "String is '%s'\n", tmpStr.getStr());

## 6. OO.oをデバッグする

## 6. Debugging OO.o

この節では、gdbはコンソールから使っていると仮定している。

This section assumes use of gdb, from the console.

### 6.1. デバッグシンボルを付けてビルドを行う

### 6.1. Building with debugging symbols

`build debug=true` コマンドをモジュール毎に行うことによって、 OO.oは、デバッグコードをモジュール毎に加える方法を含んでいる。 残念なことだが、この(方法)は、それに たっぷりのアサーション、大量 に発生しているワーニング、さまざまなその他のチェックが致命的なデバッ グシンボルを含んでおり、プロジェクト全体を実行するには勧められない。

OO.o includes a way to add debugging code in per module, via the `build debug=true` command in each module. Unfortunately this is not recommended to run for the whole project, and in addition to including vital debugging symbols it also includes scads of assertions, churning warnings, and various other checks.

このように、すべてにデバッグシンボルを付けることを望むなら、 幾つかのmakefileにデバッグシンボルを追加するように変更し、下記のパッ チを適用します。[注.この作成したOOバイナリは~1ギガバイトより小さい。 フルビルドツリーなら~8ギガバイトである]

Thus if you want debugging symbols for everything, you have to hack several makefiles to add debugging symbols, [ NB. this makes the OO binaries ~1Gb small and the full build tree ~8Gb so beware ], apply this patch:

    --- solenv/inc/unxlngi4.mk
    +++ solenv/inc/unxlngi4.mk
    @@ -92,18 +92,18 @@ cc=gcc
     # do not use standard header search paths
     # if installed elsewhere
     .IF "$(BUILD_SOSL)"!=""
    -CFLAGS=
    +CFLAGS=-g
     .ENDIF
     CFLAGS+=-fmessage-length=0 -c $(INCLUDE)
     # flags for the C++ Compiler
    -CFLAGSCC= -pipe -mcpu=pentiumpro
    +CFLAGSCC= -g -pipe -mcpu=pentiumpro
     # Flags for enabling exception handling
     CFLAGSEXCEPTIONS=-fexceptions -fno-enforce-eh-specs
     # Flags for disabling exception handling
     CFLAGS_NO_EXCEPTIONS=-fno-exceptions

     # -fpermissive should be removed as soon as possible
    -CFLAGSCXX= -pipe -mcpu=pentiumpro -fno-for-scope -fpermissive -fno-rtti
    +CFLAGSCXX= -g -pipe -mcpu=pentiumpro -fno-for-scope -fpermissive -fno-rtti

     # HACK: enable Hamburg developers to build on glibc-2.2 machines but compile vs. glibc-2.1 headers
     .IF "$(BUILD_SOSL)"==""

もちろん、デバッグシンボルなしでは、gdbは使いずらい。ベースディレ クトリにある上記のパッチを、/tmp/fooにカットアンドペーストしてパッ チを適用する。

Of course, without debugging symbols gdb becomes even more useless. To apply the patch cut and paste the above to /tmp/foo and in the base directory:

    patch -p0 < /tmp/foo

### 6.2. ブレークポイントを設定する

### 6.2. Setting breakpoints

gdbで壊れ具合によって、もっともありそうなのが、動きそうにない(バイ ナリを)実行する前にブレークポイントを設定することです。 このようなスキームが最善です。

Due to the general level of brokenness in gdb, it's most likely that setting a breakpoint before running is unlikely to work; thus the best scheme is to:

    gdb ./soffice
    break main
    run # don't forget the arguments here
    # ... traps in main ...
    break osl_readFile
    continue

もちろん、もし、コードが、巨大なOO.oのコードの大部分accountsは dlopenedした後のライブラリに実装されて、それが動くとは思っていな い。 このように、あなたは、コードがロードされて、ブレークポイントが設定 された場所で止まるのを捉える必要がある。osl_psz_loadModuleの中でパ シッとブレークポイント止めて、やってみよう。

Of course, this is never going to work if the code is implemented in a library that is dlopened later, which accounts for the vast majority of OO code. Thus, you need to trap the code loading and then put the breakpoint in. To do that whack a breakpoint in osl_psz_loadModule, and suffer.

別の方法として、コードに実行させるとするなら、(ソースコードに) #include <signal.h>を追加するのが簡単です。; そして、 raise (SIGSTOP)を(止めたい場所に)置きます。; (ソース)コードのどこ かデバッガ中でtrap out(停止用割こみを発生させる?)する。

Alternatively if you can instrument the code, it's pretty easy to add #include <signal.h> and then put a raise (SIGSTOP); somewhere in the code which will trap out in the debugger.

### 6.3. 開始の始まり

### 6.3. Starting at the beginning

われわれは、vcl/source/app/svmain.cxx (SVMain)が呼んでいるsalラッ パーのmain関数の最初にいます。それは、mainのpSVData->mpAppから呼び だされます。しかし、pSVDataはローカルのインライン(変数?)です。 デバッグをするために、グローバル変数であるpImplSVDataを使います。 例えば

          p pImplSVData->maAppData

これが典型的な 'main'メソッドです: desktop/source/app/app.cxx (Main).

We start in 'main' with a sal wrapper, that calls vcl/source/app/svmain.cxx (SVMain). It invokes Main on pSVData->mpApp; but pSVData is an in-line local. To debug this use the pImplSVData global variable. eg:

          p pImplSVData->maAppData

This 'Main' method is typically: desktop/source/app/app.cxx (Main).

### 6.4. 文字列を調べる

### 6.4. Examining strings

粗末な char *(gdbは、なにもしなくてもchar *を表示することができる) は、gdbが理解できない無数の異なるクラスで、それ(char *?)は、ラッビッ ングされているオブジェクト(指向)の世界では避けられている。さらに悪 いことに、文字列をプリントするのですら極端に難しい場合がほとんどで す。-- この結果は、ucs-2エンコードで行くというぞっとするような決定 によります。これは、変りやすい、変りにくい文字クラスの両方に言えま す。

The humble char * (that gdb can natively display) is eschewed in the object world by wrapping it with innumerable different classes that gdb doesn't understand. Worse, in many cases it is extremely difficult even to print the string — one consequence of the appalling decision to go with ucs-2 encoding. There are also both mutable and immutable string classes.

5.7.2節を読んで、OOoの中でどのように 文字列が動作しているかと、デバッグ用TIPSの知識を得てください。

Please read section 5.7.2 to see how strings work in OO.o and to get some debugging tips.

### 6.5 正しいビルドの順序を知る

### 6.5 Getting the build order right

ビルドのモジュール依存関係は、すっきりとしたビルドを行うために非常 に重要なことであるのは、明白である。モジュール中で、'build'と入力 すると、最初ビルドは、prj/build.listを調べます。たとえば、 neon/prj/build.lst:は

    xh      neon  :  soltools external expat NULL

'soltools', 'external' や 'expat' という限定詞は、満足にビルドされ、 neonがビルドできる前に望んだ結果が出なくてはならない。時々これらの ルールが壊れて、しばらくの間人々に警告されない。

The build dependencies of the modules are clearly crucial to getting a clean build. When you type 'build' in a module, first build examines prj/build.list, eg. neon/prj/build.lst:

    xh      neon  :  soltools external expat NULL

this specifies that 'soltools', 'external' and 'expat' have to be satisfactorily built and delivered before neon can be built. Occasionally these rules get broken, and people don't notice for a while.

### 6.6 gdbの中だけで落ちるんだけど

### 6.6 It crashes, but only in gdb

面白いことに — あなたが、インストールツリーの中で desktop/unxlngi4.pro/bin/sofficeをsoffice.binにリンクを張ったとす ると? 実行するだけなら、十分に動く。しかし、gdbがシンボリックリン クを展開して、パス中の(実行)バイナリの捜索をできなくし、(gdbに) argv[0]で与えられるような完全パスを渡します。これ(gdb)には、 /opt/OpenOffice/OOO_STABLE_1/desktop/unxlngi4.pro/binのようなプロ グラムのベースパスが割当てられ、そこから探し始められます。(例 applicat.rdb) もちろん、いかなる設定情報も見つけられない時は、それ は静かにどこかでクラッシュするか、元の問題から遠く離れた所にいます。

What fun — you symlinked desktop/unxlngi4.pro/bin/soffice to soffice.bin in your install tree didn't you. That works fine if you just run it, but it seems gdb unpacks the symlink and passes a fully qualified path as argv[0], which defeats the hunting for the binary in the path, so it assigns the program base path as /opt/OpenOffice/OOO_STABLE_1/desktop/unxlngi4.pro/bin and starts looking for (eg. applicat.rdb) in there. Of course when it fails to find any setup information, it silently crashes somewhere else yards away from the original problem.

### 6.7 クラッシュしたり、クラッシュしなかったりし ます

### 6.7 It crashes, but doesn't crash

様々な理由により、人生が混乱するよりはシグナルハンドラが起動されま す。それは、このように作られているのが一番です。

    --- sal/osl/unx/signal.c
    +++ sal/osl/unx/signal.c
    @@ -188,6 +188,8 @@ static sal_Bool InitSignal()
                 bSetILLHandler = sal_True;
            }

    +       bSetSEGVHandler = bSetWINCHHandler = bSetILLHandler = bDoHardKill = sal_False;
    +
            SignalListMutex = osl_createMutex();

            act.sa_handler = SignalHandlerFunction;

注. 後続のスペース

For various reasons signal handlers are trapped and life can get rather confusing; thus it's best for builders to apply something like this:

    --- sal/osl/unx/signal.c
    +++ sal/osl/unx/signal.c
    @@ -188,6 +188,8 @@ static sal_Bool InitSignal()
                 bSetILLHandler = sal_True;
            }

    +       bSetSEGVHandler = bSetWINCHHandler = bSetILLHandler = bDoHardKill = sal_False;
    +
            SignalListMutex = osl_createMutex();

            act.sa_handler = SignalHandlerFunction;

NB. trailing space.

### 6.8 トレースした結果からコードを見つけられない

### 6.8 I can't find the code from the trace

幾つかのメソッドは、コールバックとして使うことができる特別なリンケー ジを持っていると記述されている。それらは、通常'LinkStab'というプレ フィックスをつけている。 they can be used in callbacks; these typically have a prefix: 'LinkStub', so search for the latter part of the identifier in a freetext search. eg.

          IMPL_LINK( Window, ImplHandlePaintHdl, void*, EMPTYARG )

builds the 'LinkStubImplHandlePaintHdl' method.

Some methods, are described as having a special linkage, such that they can be used in callbacks; these typically have a prefix: 'LinkStub', so search for the latter part of the identifier in a freetext search. eg.

          IMPL_LINK( Window, ImplHandlePaintHdl, void*, EMPTYARG )

builds the 'LinkStubImplHandlePaintHdl' method.

### 6.9 トレースで見たファイルだけを再コンパイルするには

デバックオプションをつけないビルドでgdbを使うと、耐えられずに(例えば) oowriterの全てを再コンパイルしたくなるでしょう。だから、私達はperlのヘルプ アプリケーションを作りました。そのperlヘルプアプリケーションはスタックのな かで興味のあるメソッドやクラスの名前をコピペすることによって、それらの文字 列を含むファイルだけをtouchすることができ、再コンパイルするのが容易になり ます。以下は典型的なデバッグの流れです:

        gdb ./soffice.bin
        ...
        bt
    #0  0x40b4e0a1 in kill () from /lib/libc.so.6
    #1  0x409acfe6 in raise () from /lib/libpthread.so.0
    #2  0x447bcdbd in SfxMedium::DownLoad(Link const&) () from ./libsfx641li.so
    #3  0x447be151 in SfxMedium::SfxMedium(String const&, unsigned short, unsigned char, SfxFilter const*, SfxItemSet*) ()
       from ./libsfx641li.so
    #4  0x448339d3 in getCppuType(com::sun::star::uno::Reference const*) () from ./libsfx641li.so
    ...
        quit
        cd base/OOO_STABLE_1/sfx2
        ootouch SfxMedium
        build debug=true

こうして、SfxMediumを参照したりインプリメントしているなにもかもがtouchさ れ、それによりデバッグシンボル付きで再ビルドします。

### 6.10 あるソースディレクトリにあるファイルのみを再ビ ルドするには

もし、カレントディレクトリにあるコードのみを再コンパイルしたいのならば、 killobj dmakeターゲットを使うことによってそのオブジェクトファイルを削除 することができます:

        dmake killobj
        dmake

### 6.11 いつもsal_XErrorHdlでクラッシュするんだけど...

非同期なXエラー報告が原因です。

    export SAL_SYNCHRONIZE=1

とすることによって、全てのXの通信を同期させ、そのエラーを起こしたメソッ ドによりエラーを報告するようになるが、OOoの動作をぐんと遅くもさせます。

### 6.12 ワードファイルを読み込んだら黙って落ちるんだけ ど...

Caolanの提案するには: ww8par.cxxのSwWW8ImplReader::LoadDocの最初と最後に ブレイクポイントを置くことによって、できるかぎり重要なフィルタをドキュメ ントが得ることを確認します。

熟練者はSwWWI8ImplReader::ReadPlainCharsにブレークポイントを置けば、読 み込まれたテキストの塊を見ることができます。あるいは、 SwWWI8ImplReader::AppendTxtNodeは挿入された各段落を見ることができます。

## 7. パッチを配布するには

### 7.1. Diffスタイル

常に'cvs -z3 diff -u'としてunified形式を使ってください。なぜならば、それ が一番見やすく、しかも読んで適用するのに適切なdiffのタイプだからです。

### 7.2. うまく取り込んでもらうためには

手を動かす前に、どうやったらあなたのパッチをうまく取り込んでもらえるのか ということを考えたり、開発者とそのことについて相談したりするのはよいこと です。 そのうちのお薦めの方法は、dev@openoffice.orgに投稿するか `irc.freenode.net`の`#OpenOffice.org`チャンネルにIRCで潜ん でいることです。IRCはとても使えないコミュニケーション媒体ですが、コミュ ニケーションをしないよりはましでしょう。ここ を見れば、誰が誰だかがわかります。

### 7.3. ooo-buildパッチの作り方

私達のパッチインフラについてのより多くを知りたければここを見てください。

## 8. その他、TIPS

### 8.1. CVSアカウントを取得する

Issueが報告される過程がどのようになっているのか見るには例えばissue #7270 を見てください。アカウントを取得したら、まず以下のようにしてセキュアCVS サーバにトンネルを作る必要があります。

    ssh -f -2 -P -L 2401:localhost:2401 tunnel@openoffice.org sleep 1400 < /dev/null > /dev/null

そしたら、トンネルの終端をローカルマシンにするために、CVSROOTをローカルマ シンのところに変更しましょう。

    :pserver:mmeeks@localhost:/cvs

ログインすると、すぐにあなたのCVSの設定を新しいサーバに移さなければいけ ないことに気づくでしょう。これをB/Wを無駄にせずにやるには:[遅いけど効果 的です]

    echo ":pserver:<account-name-here>@localhost:/cvs" > /tmp/Root
    find -name 'Root' -exec cp /tmp/Root {} \;
    find -name 'Repository' -exec perl -pi.bak -e 's/^oo\///' {} \;

### 8.2 patchやdiffを使う

patchやdiffは素晴らしいツールです。しかし、人々はこれらのツールを混乱させ、 その解決が困難なデータを渡すことがよくあります。以下は、これらの混乱を解決 するためのいくつかのヒントです。

- 自信がなかったら、まず--dry-runオプションを付けてpatchコマンドを実行し ましょう。これはpatchを作っているように見えますが、実際にpatchを作って いるわけではありません。これは内部依存のパッチの組合せとともにインチキ な結果を返すことがありますが、しかしそれを補ってあまり余る便利さがあり ます。
- たいていの場合は"patch -p0"としてください。0はdiffが示すファイルパスの 先頭からいくつのスラッシュ(とその間にあるディレクトリ名)を取り除くかを表 します。
- 途中でわけ分からなくなって、パッチの半分がすでに適用されてしまって、元 戻したいというときには、ファイルを消去してCVSでアップデートするか、-Rオ プションを付けてパッチをあて直します。
- たまに、diffを空白の変更が沢山あるモジュール間で使うとパッチが読みづら なります。diffで'-w'フラグを利用すればこの問題を読みやすくなります。

### 8.3 make clean

トップレベルディレクトリでdmake cleanとするだけです。HEADにはclean ターゲットがありませんが、dmake cleanがやっていることをやっていることの代 わりとして、以下のようにします。

    find -name 'unxlngi4.pro' -exec rm -Rf {} \;

### 8.4 CVSの設定

バンド幅を効率よく利用するためには、適切なdiffをデフォルトで作るようにしま しょう。~/.cvsrcに以下の記述を追加しましょう。

    cvs -z3 -q
    diff -upN
    update -dP
    checkout -dP
    status -v

### 8.5. ヘッダファイルを追加する

分かっているとは思いますが、OOoにヘッダファイルを追加するのは面倒です。 ヘッダファイルをexternal/に追加するには、ヘッダファイルを external/prj/d.lstに追加しましょう。ビルドするときに solver/641/unxlngi4.pro/inc/externalディレクトリにコピーされます。

### 8.6. Finding where to hack

Often there is some GUI element used near the thing you're trying to locate / fix. So, find some sufficiently unusual string and search for it in LXR's text search; this should reveal an identifier related to that string; eg. SID_AUTOFORMAT, or FN_NUM_BULLET_ON. Having obtained that, do a new text search for that string, and you'll find the usage [ or a chained define to something else ]. For eg. menus/toolbar buttons the functionality is usually in a case statement eg. case SID_AUTOFORMAT: ...

## 9. 有用なリンク集

### 9.1. www.OpenOffice.org

初期のOpenOffice.orgという組織のほとんどがハッカー志向のものではありませ んが、ちょっと探せば便利なドキュメントが沢 山あります。

OOoのニュースや、他には無い独特のOOoの情報を知りたければooodocs.orgを見てください。

他には: OOODIはGtk+ディクショナリイン ストーラーを制作しています。 OOExtrasはテンプレートやマ クロ、クリップアートを提供しています。 Quickstart appletはGnome向 けですが、KDE向け のもあります。 Dictionaries & DocsはKevin Hendricksによる提供です。

### 9.2. Patch archives

OpenOffice.orgが沢山のリリースをしている一方で、異なるプロジェクト同士が OOoに対して沢山のパッチ(しかもでかい奴)を投げます。幸いにも、かなりの割 合で折り返すことができるので、どのパッチもビルドするためにHEADには必要あ りません。例えば、多くのものがOOO_STABLE_1に取り入れられました。それにも かかわらず、これらのいくつかあるいは全てを利用することは必要です。

- Ximianのパッチとビルドツールやスナップ ショットは全てパッケージまたはパッチとして利用可能です。
- Debianの役に立つOOoのページにはパッチがありま す。Debianの CVSも有用です。
- MandrakeのOOo パッチ集。
- FreeBSDのOOo portのパッチ。
- Red Hat'sの(Mandrakeのに基づいた).specファイルも読む価値があり、Red Hat のSRPMにあります。
- OOoをローカライズしたい人はPavel Janikによるパッチを見て勉強しましょう。

## 10. (めったにない) FAQ

### 10.1. どうして'mws_srx644'などといったブランチは奇数 番号をとらないのか？

週ごとにフリーズしsolverや開発環境がリリースされるため、この値は週ごとに 増え、発散します。しかし、最近幅広いリリースのための単体のビルドを作るプ ロセスが困ったことに一週間以上かかるために英数字が混じったリリースタグが うたれます。mwsはMaster Workspaceを意味します。

### 10.2. どうしてビルドするのにJavaがいるの?

どうしても、コンポーネントやいろんなサービスを登録するのに沢山のXMLファ イルが必要になります。Javaを使えばこれらの操作が簡単に行えます。さらに、 Javaがマシンにインストールされていれば、OOoを実行するときにもうまい具合 にJavaが使われます。

### 10.3. なんで[t]cshは使えないの?

これは少しばかり不可解です。コマンドを標準出力にパイプする方法が端末から 入力するのとで、決定的に違います。

    echo 'echo #define DLL_NAME "libsch641li.so" >./foo.hxx' | /bin/tcsh -s

は、同じものをシェルで打ったらうまくいくのに、失敗します。なんか変ですが、

    tcsh -fc 'echo #define DLL_NAME "libsch641li.so" >./foo.hxx'

ならうまくいきます。cshも参考 にしてください。

### 10.4. ビルドの場所を移動させたのだけれど、なんでうま くいかないの ?

    relocate /path/to/new/build/

を実行させなければいけません。 他の面倒な方法として、再設定しなればいけないもの(LinuxIntelEnv.Setも新し いパスが必要だし、シェルに再インポートしなければいけません。)があり、相 対パスで記述されていないので、

The simple answer is: you need to run

    relocate /path/to/new/build

; another more complex answer is:

Well, assuming you have re-configured things (LinuxIntelEnv.Set will need paths tweaking too — and re-importing to your shell) — then it's most likely down to the ubiquitous non-relative paths, coded in lots of generated / built files, particularly '.dpc*' (dependency) files. Try:

    find -name '*.dpc*' -exec rm {} \;

The stlport does some really broken things, so you will also need to edit the 'stl_gcc.h' inside the solver/, and replace the two path instances there (see inc/stl/config/stl_gcc.h).

### 10.5 CVSが'Fatal Error aborting. [acc] no such user' というエラーを吐きます。どうして？

あなたのユーザ名が登録されていないことが考えられます。大抵はあなたの~ /.cvspassが失われて、すでにログアウトされているのが原因です。ログインし なおして、同じコマンドを打ってみてください。

### 10.6 'unxlngi4.pro'の'.pro'は何を意味してるの?

Productです。こんなん明らかでしょ。

### 10.7 OpenOffice.orgってどんな感じでできてるの?

さっきこんな図を見つけてきたので、貼っておきます。

### 10.8 どうやってOOoのスクリーンショットを撮るのですか?

OOoはX resoucesにとても変なことをします。このように古いスクリーンショッ トをとるアプリケーションは正確なスクリーンショットを撮ることができませ ん。しかし、ImageMagickのimportコマンドは使えます。

    import foo.png

あるいは、

    sleep 2; import ^window root foo.png

とコンソールで打ちます。 (注)スクリーンを小さく見せたいのでなければ、ツールバーのアイコンをまず 大きくする必要があります。

### 10.9 I tried to build with gcc on a prefix with BUILD in it why does it break ?

This is due to some very serious crack smoking going on in stlport. Essentially, there is some nasty header overriding, and they want to be able to fallback to the previous header (with the same name) - thus they have to hard-code the paths. To save doing that in lots of places, they use a #define, the #define has macro expansion done on it. Thus if your gcc prefix contains an element which is a macro - you're stuffed:

stlport config header:

    #define _STLP_NATIVE_INCLUDE_PATH \
            /home/michael/ximian-desktop/ooo/BUILD/ooo/include/c++/3.2.2

stlport helpful macros:

    # define _STLP_MAKE_HEADER(path, header) <path/header>
    # define _STLP_NATIVE_CPP_C_HEADER(header)  \
            _STLP_MAKE_HEADER(_STLP_NATIVE_INCLUDE_PATH,header)

and finally stlport cunning native include:

    #include _STLP_NATIVE_CPP_C_HEADER(foo)

Net result:

          g++ ... -DBUILD=7663 ...
          ...
    from /home/michael/ximian-desktop/ooo/BUILD/ooo/OOO_1_0_2/xml2cmp/source/xcd/main.cxx:62:
    /home/michael/ximian-desktop/ooo/BUILD/ooo/OOO_1_0_2/solver/641/unxlngi4.pro/inc/stl/cstddef:35:46:
    /home/michael/ximian-desktop/ooo/7663/ooo/include/c++/3.2.2/cstddef: No such file or directory

### 10.10 UNOコンポーネントのXML descriptionはなんのた めにあるの ?

大したものではありません。インストールするときに意味がありますが、しかし いまのところほとんど使われていません。

### 10.11 なんでこんなにコードが見づらいのか?

コードを書く人は変なエディタを使わなければいけません。タブストップは4文 字になっていると思われます。もちろん、タブ幅が8文字と思われるUnixのエディ タで編集したファイルは見づらくなります。

もしたまたま 本物のエディタを使って いるのであれば、ピンク色の眼鏡を売ります。 http://ooo.ximian.com/emacs.el を`.emacs`に貼りつけるか、あるいはこのファイルを`(load "/path/to/that/file.el")`として読みこんでください。 `my-openoffice-path-regexp`を自分の環境に適合させるのを忘れないで ください。

これにより、emacsはOOoのソースファイルには4文字幅のタブを使います。 (さらに、`sdi`、`hrc`、`src`ファイルに対するC++ モードにも同様に4文字幅のタブを使います。)

## 11. 私たちと一緒に作業しよう

About ooo-buildをみてください。

If you have more hacking tips, corrections, a grip of correct spelling etc. please do mail me, at michael.meeks@novell.com.

《訳注：翻訳に関することは, yabuki [at] netfort.gr.jp へ。必ず応答できるとは限りませんが, 具体的な訂正意見は歓迎します.》 《訳注：翻訳は, Yukiharu YABUKI と Takashi Nakamoto が行いました.》