diff options
| author | Hubert Figuiere <hub@figuiere.net> | 2007-09-28 00:13:10 +0000 |
|---|---|---|
| committer | Hubert Figuiere <hub@figuiere.net> | 2007-09-28 00:13:10 +0000 |
| commit | 6deff60a16b7ef59eed95c7ecdadf70b7e201646 (patch) | |
| tree | 77a7f2aab9969b32a5e26373f2ce801bb3161404 /developers | |
| parent | 4d55f5f69518823ad760538cca8b75a501012b3a (diff) | |
Missing links and guides
Diffstat (limited to 'developers')
| -rw-r--r-- | developers/cws-quickhowto-ja.html | 239 | ||||
| -rw-r--r-- | developers/cws.html | 185 | ||||
| -rw-r--r-- | developers/hackers-guide-de.html | 1275 | ||||
| -rw-r--r-- | developers/hackers-guide-ja.html | 1658 | ||||
| -rw-r--r-- | developers/hackers-guide.html | 1202 | ||||
| -rw-r--r-- | developers/index.php | 4 | ||||
| -rw-r--r-- | developers/old-guides.html | 30 |
7 files changed, 4591 insertions, 2 deletions
diff --git a/developers/cws-quickhowto-ja.html b/developers/cws-quickhowto-ja.html new file mode 100644 index 0000000..570523a --- /dev/null +++ b/developers/cws-quickhowto-ja.html @@ -0,0 +1,239 @@ +<!doctype html PUBLIC "-//W3C//DTD HTML 4.0//EN"> + +<html lang="ja"> +<head> +<meta lang="ja" http-equiv="content-type" content="text/html; charset=utf-8"> +<title>** CWS tooling quick howto +** CWS ツール クイック HOWTO</title> +</head> + +<body> +<H1>** CWS tooling quick howto<br> +** CWS ツール クイック HOWTO</H1> + +<a href="./index.html">back to index</a> + +<pre> +From Jens-Heiner.Rechtien@sun.com Fri Jul 9 12:46:16 2004 + +Hi, +やぁ + +we are ready to go live with the CWS tooling. The stuff probably still +has some rough edges here and there, it's essentially an adaption (done +by Vladimir and me) of the in-house tools we use for some time now here +in Hamburg. Sorry Volker, I haven't been able to add your patches yet, +so for the time being this is still Unix only. +私達は、CWSツールと一緒にやっていく準備ができた．この素材はまだ， +そこかしこにあらがをあるが，いま，ここハンブルグで我々が内部で使っている +ツールと本質的には互換性(これはVladimirと私がやった)がある．Volkerすまない， +私は，まだ君のパッチを適用出来ていない，今回は，Unixだけだ． + + +The following is just a short description of the tooling, the real +documentation is here: +http://tools.openoffice.org/dev_docs/ooo-cws-tools-doc.sxw +ツールについての簡単な説明は以下にをある，また本格的なドキョメントは， +http://tools.openoffice.org/dev_docs/ooo-cws-tools-doc.sxw +にある． + +This tooling is for committers only, most of it (with the possible +exception of 'cwsquery' and 'cwsanalyze') doesn't make sense for the +general public. +このツールはコミッターだけのものである．多くのツール('cwsquery' や +'cwsanalyze'は例外の可能性がある)は，一般に開放するのには納得できない． + +The Prerequisites: +先行条件: +================= + +1) The following perl modules need to be installed: +1) 以下のperlモジュールがインストールしてある必要があります． +XML::Parser -> expat based parser for the new XML based build lists + build listを元としてexpatをベースとした新しいXMLパーサーです． +Config::Tiny -> parsing .cwsrc configuration files + .cwsrc設定ファイルのパーサー +Crypt::SSLeay -> for SSL encrypted SOAP connections + SSLで暗号化されたSOAP接続 +SOAP::Lite -> access the SOAP based CWS web service + SOAPベースのCWSのwebサービスへのアクセス + +2) A valid OOo CVS account. The CWS tooling connects via HTTPS to the +OOo CWS web service. As credentials is the OOo account name and the CVS +style scrambled OOo password presented. The web service then uses the +credentials to verify the legitimacy of the user with the help of the +OOo CVS server. +2) 正規のOOoのCVSアカウント．CWSツールはHTTPS経由でOOoのCWSウェブサービスへ接続する．信頼するべきものは，OOoアカウント名とCVS形式で暗号化されたOOoパスワードの存在である．このWebサービスの時には，OOo CVSサーバーの助けとしてユーザーの整合性チェックをするために この信頼するべきもの を使う．(訳注：信頼するべきものとは，アカウント名とcvs形式で暗号化された一組のリストを指す) + +3) A configuration file called $HOME/.cwsrc. I've attached an example. +Enter you VCSID, scrambled CVS password, the CVS tunnel etc. +3) $HOME/.cwsrcにある設定ファイルが呼び出されます．例を添付します． +VCSID，暗号化したCVSのパスワード，CVSトンネルなど が入ってます． + +4) Check out solenv/bin and solenv/bin/modules toplevel. You'll get a + bunch of perl scripts. The tools are: +4) solenv/binとsolenv/bin/modulesのディレクトリーを調べてみてください． + あなたは，ひとかたまりになったperlのスクリプトを取得できるでしょう． + それらのツールは、 + a) cwsquery query misc. stuff from the CWS database + a) cwsquery 様々な問合せ．CWSデータベースを元にする + b) cwscreate create a CWS + b) cwscreate CWSを作成する + c) cwsadd add modules to the CWS + c) cwsadd CWSへモジュールを追加する + d) cwsaddtask add tasks to the CWS + d) cwsaddtask CWSへタスクを追加する + e) cwsresync resync a CWS to a new milestone + e) cwsresync 新しいマイルストーンのためにCWSと同期する + f) cwsanalyze analyze a CWS, compare it to the current master + f) cwsanalyze CWSを分析する．現在のマスタと比較する． + + +How it works: +============= + +1) Check out the Openoffice alias, configure, source the script. +1) configureスクリプトとソースコードが含まれているOpenOfficeというエイリ + アスをチェックアウトする」(訳注：ソースコードをCVSからチェックアウト + しなさい! ということか) + + +2) To check the connection please do something like this +2) 接続をチェックするために下記のようにしなさい. + + $ cwsquery -m SRC680 latest + + This command should print the latest released milestone for SRC680 + このコマンドは，SRC680最終リリースのマイルストーンが表示されます． + +3) Create a CWS: +3) CWSを作ります: + + $ cwscreate SRC680 m44 mycws01 + + This creates a CWS based on SRC680 m44 called 'mycws01' (no + underscores and other funny characters please ...) + SRC680 m44をベースとしてCWSを作成したのを 'mycws01'と呼びます． + (_や他の変な文字を使わないで お願い....) + + ATTENTION: This updates your workspace to the mentioned milestone, so + make a copy if you have modified files in there. + 注意：そこにある変更したファイルがあるなら，複製を作る．そのマイル + ストーンに言及するためにあなたのワークスペースを更新する． + +4) set the CWS_WORK_STAMP environment variable +4) CWS_WORK_STAMP環境変数を設定する + + $ setenv CWS_WORK_STAMP mycws01 + +5) add some modules +5) モジュールを追加する． + + $ cwsadd tools sal + +6) Add some tasks to the CWS +6) CWSへタスクを追加する + + $ cwsaddtask i4711 i123456 + +7) Modify files on your CWS ... +7) あなたのCWSで，ファイルを変更する． + +8) Analyze your CWS in a scratch directory. +8) CWSにある変更したディレクトリを分析する + + $ cd /tmp + $ cwsanalyze all + + This will tell you how many conflict you'll have with the current + HEAD of the master. You can try this with every CWS, even with old + ones which have long been integrated + 現在のマスターのヘッド(ブランチ)を使っているだろうから，これにより + どれだけ差異があるかが判ります．すでに統合されている古い版ですら， + CWS毎に試すことができます． + +9) Resync to a newer milestone. This is a 5 step operation (the + fifth step is optional) +9) 新しいマイルストーンに再同期します．これは，5ステップの操作です． + (5つのステップは，任意です．) + + $ cd /tmp + $ cwsresync -m m45 all + $ .. resolve your conflicts + $ cwsresync -c all + $ cwsresync -l m45 + $ cwsresync -r + + The -m step merges your files and protcolls all conflicts etc. + -m ステップは，あなたのファイルを併合し，全ての競合を解決します + (訳注：protocol?には動詞の意味はないけど，この意味が妥当かと) + The -c step commits the merges to the CVS. Do it always with + cwsresync -c, never by hand!! + -c ステップは，CVSに変更をコミットします．これは cwsresync -c + で行なうこと，絶対手でやらないで!! + The -l step updates your workspace and updates the milestone info + of the CWS in the database + -l ステップは，ワークスペースの更新と データベースの中に CWSの + マイルストーン情報を更新する． + The optional -r step removes solver and module output tree from your + workspace. New milestones are almost always incompatible. + 任意である -r ステップは，solverとワークスペースからモジュール + 出力ツリーをを削除します．新しいマイルストーンは，ほぼ必ず完全でない． + +Caveats +======= +補足説明 +======== + + +- does not yet work on Windows, but will RSN. +- Windowsの上ではまだ動いていない．でも，大急ぎでやるだろう． +- still has some rough edges (spellling mistakes etc), probably a bug or + two :-) +- まだ荒削りである(綴間違いなど)，バグも1，2個あるだろう． + +Heiner + +-- +Jens-Heiner Rechtien +rechtien@sun.com + + + +--------------010205020207000104050109 +Content-Type: text/plain; name=".cwsrc" +Content-Disposition: inline; filename=".cwsrc" +Content-Transfer-Encoding: 8bit + +[CWS_CONFIG] +# Network proxy. Comment in if you need to access the net via a proxy. +# Example: PROXY=http://myproxy.company.com:8080 +# PROXY= + +# CWS Database server (SOAP). It's possible specify to several backup server, +# currently there are none. +CWS_DB_SERVER_1=https://eis.services.openoffice.org/soap/servlet/rpcrouter + +# Your CVS login (for authentication with the CWS database). +CVS_ID= + +# Your scrambled CVS password (for authentication with the CWS database). +# Take this one from .cvspass (should be last field on the line and look +# like "Aac`l;kde" or something like that) +CVS_PASSWORD= + +# OOo CVS tunnel +# Example: CVS_SERVER_ROOT=pserver:cvs_id@mytunnel.mydomain.de:/cvs +CVS_SERVER_ROOT= + +# Local OOo CVSUP mirror (optional) +# Example: CVS_MIRROR=:pserver:cvs_id@mycvsup.mydomain.de:/cvs +#CVS_MIRROR_ROOT= + +# Path to the cvs binary (optional) +# Example: CVS_BINARY=/usr/bin/cvs +#CVS_BINARY= + +</pre> +</body> +</html> diff --git a/developers/cws.html b/developers/cws.html new file mode 100644 index 0000000..c232d0f --- /dev/null +++ b/developers/cws.html @@ -0,0 +1,185 @@ +<html> +<body> +<h1>The even quicker hackers' CWS howto</h1> +<p> + For a lengthier cws explanation see <a href="cws-quickhowto.txt">here</a>. +This text, is some really, really bare bones for the quickest, most simple +cws usage; all fields that you'll need to change are italic for ease. +</p> +<p> + The basic overview here is that a CWS is a CVS branch, tied to a +database called <a href="http://eis.services.openoffice.org/EIS2/servlet/GuestLogon"> +EIS</a>. The <code>cws*</code> tooling talks to both the CVS server +and (via SOAP) to the database. It makes maintaining branches more +efficient, standardises their use & integrates with QA nicely. +</p> +<p> + All code that goes into OO.o has to go through a CWS. A CWS is a +fairly heavy-weight beast - thus it's well worth aggregating several +commits / bug-fixes into one. +</p> +<p> + NB. Since this 'howto' was written an <b>even</b> quicker way of +committing patches to a cws has been knocked up by Kendy it is here: +<a href="http://go-oo.org/ooo-build/bin/cws-commit-patch"> +cws-commit-patch</a>, and works well. +</p> + +<h3>Basic setup / Assumptions</h3> +<p> + It is assumed that you have fixed some bug / created some feature, +and you have a live build tree in <i>/opt/OpenOffice/src680-m76</i>. +It is also assumed that you have sourced the LinuxIntelEnv.Set.sh +script and have you shell setup right. +</p> +<p> + It is also assumed that you have an up-stream OO.o cvs account, +and that you have your tunnel setup correctly, and the source has +the right CVS/Root entries for that account/tunnel. +</p> + +<h3>Creating the cws</h3> +<p> + You have to think of an imaginative name for your cws; if it's just +some general bug fixing thing, people tend to use +account-name<index> otherwise some more descriptive name +</p> +<p> + <code> + cwscreate <b>-f</b> SRC680 <i>m76</i> <i>link01</i> + </code> +</p> +<p> + NB. the -f stops cwscreate doing a slow, monstor fresh + check-out (you don't want that). +</p> +<p> + NB. cwscreate in this mode: SOAP only, no CVS access. +</p> +</body> + +<h3>Setting up the environment</h3> +<p> + Now we created a cws - we need to tell the tooling we're +working with this cws; we do: +</p> +<p> + <code> + export CWS_WORK_STAMP=<i>link01</i> + </code> +</p> + +<h3>Adding tasks</h3> +<p> + The CWS (in order to ever get merged) has to have a number of +issues associated with it, describing the bugs fixed in this CWS. +The developer should mark these as 'Fixed' as he commits/tests +& QA should mark these bugs 'Verified'. It's also important to +get the Milestone correct in the bug. To associate the task with +the cws do: +</p> +<p> + <code> + cwsaddtask <i>i24253</i> + </code> +</p> +<p> + NB. cwsaddtask: SOAP only, no CVS access. +</p> + +<h3>Adding modules</h3> +<p> + We now need to add some top-level modules to the CWS - the +ones that we have changed. This tool essentially just tags cvs +twice with a static: CWS_SRC680_<i>LINK01</i>_ANCHOR tag and +a cws_src680_<i>link01</i> branch tag to commit to. It then +updates the module to that branch. +</p> +<p> + <code> + cwsadd -a <b>-f</b> <i>solenv</i> + </code> +</p> +<p> + NB. here -f allows you to keep your changes, while doing the +tagging on the underlying versions they are based on - +incorporating them into the new cws automatically. +</p> +<p> + NB. cwsadd: SOAP and CVS access. +</p> + +<h3>Committing code</h3> +<p> + Committing requires nothing particular new; the database +doesn't track commits. Just commit them to the branched +modules you cwsadded. +</p> +<p> + CVS should add some helpful fields for you & some helpful +blurb about what to write here - often it doesn't. The stock +format is: +</p> +<pre>Issue number: #i<i>24253</i># +Submitted by: <i>mmeeks</i> +Reviewed by: <i>mmeeks</i> +This patch fixes a silly bug in linkoo +</pre> + +<h3>When you're happy</h3> +<p> + Finally - when you've committed everything & tested it, +and/or if you're strange & like to have a long-term cws open +you need to setup your cws details in +<a href="http://eis.services.openoffice.org/EIS2/servlet/GuestLogon"> +EIS</a>. +</p> +<p> + Login with your SourceCast account details (log out first). +Navigate the SRC680 'new' tree - find your cws, and click on +the underlined link at the top. Fill out all the details, +dates in the format <b>2005-08-02</b>. +</p> +<p> + Having done all that, go-back, and re-edit the details - +marking the state to 'Ready for QA' [ you did mark all your +bugs 'FIXED' first ? - don't run foul of the thought police ]. +</p> + +<h3>What next ?</h3> +<p> + You get to wait until the CWS is nominated by Sun QA up-stream, +then it will (eventually) be merged into HEAD and released. +</p> + +<h3>Updating to a newer milestone</h3> +<p> + The long-term CWSes need a resync to a newer milestone from time to time. +</p> +<p> +<pre> +mkdir tmp +cd tmp +cwsresync -f <b>-m m79 all</b> +<i>... resolve possible conflicts ...</i> +cwsresync -f <b>-c all</b> +cwsresync -f <b>-l m79</b> +</pre> +</p> +<p> + You must start in an empty directory with a correctly set CWS_WORK_STAMP +environment variable. First of all, <b>-m</b> merges files from the CWS +(according to CWS_WORK_STAMP) with the specified milestone and protocolls all +conflicts. <b>-c</b> then commits the merges to the CVS. NB.: Do it always +with <code>cwsresync -c</code>, never by hand! Finally, <b>-l</b> updates the +workspace and the milestone info of the CWS in the database<br/> +</p> +<p> + NB.: Don't forget to create a new & empty directory for this. Really. +</p> +<p> + NB. -f: Speeds the things up by avoiding unnecessary updates. +</p> + +</body> +</html> diff --git a/developers/hackers-guide-de.html b/developers/hackers-guide-de.html new file mode 100644 index 0000000..19f1959 --- /dev/null +++ b/developers/hackers-guide-de.html @@ -0,0 +1,1275 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> +<HTML> +<HEAD> + <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=windows-1252"> + <TITLE>Unofficial OpenOffice Hacker's guide</TITLE> + <META NAME="GENERATOR" CONTENT="OpenOffice.org 1.1.3 (Win32)"> + <META NAME="CREATED" CONTENT="20041014;10400826"> + <META NAME="CHANGED" CONTENT="20041107;19342713"> + <STYLE> + <!-- + @page { size: 8.5in 11in } + P.list-1-cont- { margin-left: 0.2in; margin-bottom: 0.08in } + --> + </STYLE> +</HEAD> +<BODY LANG="en-US" DIR="LTR"> +<TABLE CELLPADDING=2 CELLSPACING=2 STYLE="page-break-before: always"> + <TR> + <TD> + <P><A HREF="http://ooo.ximian.com/hackers-guide.html">English</A></P> + </TD> + <TD> + <P><A HREF="http://ooo.ximian.com/hackers-guide-ja.html">Japanese</A></P> + </TD> + <TD> + <P><B>German</B></P> + </TD> + </TR> +</TABLE> +<H1 ALIGN=LEFT><FONT SIZE=6>Anleitung zum Hacken von OpenOffice.org</FONT></H1> +<P ALIGN=LEFT><BR><BR> +</P> +<P ALIGN=LEFT><FONT FACE="Times New Roman, serif">Um OpenOffice.org +(OOo) zu hacken/builden, bedarf es schon einiges an Geduld.</FONT></P> +<P><FONT FACE="Times New Roman, serif">Dieses Dokument wird auf den +kommenden Seiten versuchen, die Lernkurve steil verlaufen zu lassen +und hoffentlich deinen Weg darauf erleichtern.</FONT></P> +<P><FONT FACE="Times New Roman, serif">Es nimmt an, dass du ein +relativ aktuelles und vernünftiges Linux System benutzt und dich +ausreichend mit PC Programmierung auskennst (C++ wird vorausgesetzt, +es sei denn du willst dir nur mal einen Überblick über den +Buildablauf OOo's verschaffen).</FONT></P> +<P><FONT FACE="Times New Roman, serif">Wahre Hacker benutzen </FONT><A HREF="http://www.gnu.org/" NAME="gnu"><FONT FACE="Times New Roman, serif">freie +Software</FONT></A> <FONT FACE="Times New Roman, serif">und haben +keine Zeit sich mit "unfreiem Zeug" zu beschäftigen. +Ich persönlich empfehle hier neben OOo, SuSe && Gnome.</FONT></P> +<P><FONT FACE="Times New Roman, serif">Wir werden zumindest die +folgenden Fragen beantworten: </FONT> +</P> +<UL> + <LI><P STYLE="margin-bottom: 0in"><FONT FACE="Times New Roman, serif">Wie + builde ich OOo? </FONT> + </P> + <LI><P STYLE="margin-bottom: 0in"><FONT COLOR="#000000"><FONT FACE="Times New Roman, serif"><SPAN STYLE="background: transparent">Wie + gehe ich mit einer Entwicklungs-Iteration um?</SPAN></FONT></FONT></P> + <LI><P STYLE="margin-bottom: 0in"><FONT FACE="Times New Roman, serif">Wie + kann ich OOo debuggen?</FONT></P> + <LI><P STYLE="margin-bottom: 0in"><FONT FACE="Times New Roman, serif">Wie + kann ich einen "Patch" einsenden?</FONT></P> +</UL> +<P STYLE="margin-bottom: 0in"><BR> +</P> +<P STYLE="margin-bottom: 0in"><BR> +</P> +<P><FONT FACE="Times New Roman, serif">Wenn du Hilfe brauchst an den +Ximian ooo-Build zu gelangen oder beim Hacken mithelfen willst, dann +trete bitte der </FONT><A HREF="http://lists.ximian.com/mailman/listinfo/openoffice" NAME="xi-mailinglist"><FONT FACE="Times New Roman, serif">Mailing-Liste</FONT></A> +<FONT FACE="Times New Roman, serif">bei (Kommunikation auf englisch). +Dort werden deine Fragen sicher beantwort werden.</FONT> +</P> +<P>Die deutsche Version wird versuchen in möglichst vielen +Situationen deutsche Wörter zu benutzen, jedoch ist klar, dass +es auch eine ganze Menge an Begriffen in der IT Welt gibt, die im +Sinne ihrer Originalität im Englischen verbleiben, oder sollte +ich einen "OOo build" -> "OOo Bau" nennen? +Dies nur mal als Beispiel. Ihr habt Kritik? Nehm ich gern an, <A HREF="mailto:christian@treesforlife.org">hier</A> +gehts lang.</P> +<H2><A NAME="section-0"></A>0. Inhaltsverzeichnis</H2> +<UL> + <LI><P CLASS="list-1-cont-"><A HREF="#section1"><FONT FACE="Times New Roman, serif">1. + OOo herunterladen</FONT></A></P> + <LI><P CLASS="list-1-cont-"><A HREF="#section2"><FONT FACE="Times New Roman, serif">2. + OOo builden</FONT></A></P> + <LI><P CLASS="list-1-cont-"><A HREF="#section3"><FONT FACE="Times New Roman, serif">3. + OOo installieren</FONT></A></P> + <LI><P CLASS="list-1-cont-"><A HREF="#section4"><FONT FACE="Times New Roman, serif">4. + OOo ausführen</FONT></A></P> + <LI><P CLASS="list-1-cont-"><A HREF="#section5"><FONT FACE="Times New Roman, serif">5. + OOo hacken</FONT></A></P> + <LI><P CLASS="list-1-cont-"><A HREF="#section6"><FONT FACE="Times New Roman, serif">6. + OOo debuggen</FONT></A></P> + <LI><P CLASS="list-1-cont-"><A HREF="#section7"><FONT FACE="Times New Roman, serif">7. + Patche bereitstellen</FONT></A></P> + <LI><P CLASS="list-1-cont-"><A HREF="#section8"><FONT FACE="Times New Roman, serif">8. + Sonstige Tipps</FONT></A></P> + <LI><P CLASS="list-1-cont-"><A HREF="#section9"><FONT FACE="Times New Roman, serif">9. + Nützliche Links</FONT></A></P> + <LI><P CLASS="list-1-cont-"><A HREF="#section10"><FONT FACE="Times New Roman, serif">10. + (F)AQ</FONT></A></P> + <LI><P CLASS="list-1-cont-" STYLE="margin-bottom: 0in"><A HREF="#section11"><FONT FACE="Times New Roman, serif">11. + Mit uns arbeiten</FONT></A></P> +</UL> +<P CLASS="list-1-cont-" STYLE="margin-bottom: 0in"><BR> +</P> +<P CLASS="list-1-cont-" STYLE="margin-bottom: 0in"><BR> +</P> +<P><FONT FACE="Times New Roman, serif">Der gesamte Prozess ist +ausführlicher in der </FONT><A HREF="http://ooo.ximian.com/detailed-build-guide.html"><FONT FACE="Times New Roman, serif">detaillierten +Fassung</FONT></A> <FONT FACE="Times New Roman, serif">(englisch) +<FONT FACE="Times New Roman, serif">dargestellt</FONT>.</FONT></P> +<P><FONT FACE="Times New Roman, serif">Wir haben jedoch hart daran +gearbeitet einen stabil durchführbaren Prozess für reine +Programmierer bereitzustellen, und die einfache Version folgt nun..</FONT></P> +<H2><A NAME="section1"></A><A NAME="section-1"></A>1. OOo +<SPAN STYLE="background: transparent"><FONT COLOR="#000000">herunterladen</FONT></SPAN></H2> +<P><FONT FACE="Times New Roman, serif">Es gibt eine riesige Menge an +konkurrierenden OOo Versionen und viele Auswahlmöglichkeiten an +Zweigen ("branches") mit vielzähligen qualitativen +Patch Zusammenstellungen.</FONT></P> +<P><FONT FACE="Times New Roman, serif">Ich empfehle CVS snapshots, +die bekannt sind ordentlich zu builden, und mit Patch +Zusammenstellungen, die sich einwandfrei einbinden lassen.</FONT></P> +<P><FONT FACE="Times New Roman, serif">Um den <SPAN STYLE="background: transparent">Sourcecode<FONT COLOR="#000000"> +</FONT></SPAN>zu erhalten gehen wir wie folgt vor:</FONT></P> +<PRE>export CVSROOT=':pserver:anonymous@anoncvs.gnome.org:/cvs/gnome' +cvs login +cvs -z3 checkout -P ooo-build</PRE><P> +<FONT FACE="Times New Roman, serif">Das wird eine Kopie des OOo-build +(= OOo ximian version) Baumverzeichnisses bereitstellen. Wenn du CVS +nicht magst, dann kannst du auch eine aktuelle Version von </FONT><A HREF="http://ooo.ximian.com/packages"><FONT FACE="Times New Roman, serif">hier</FONT></A> +<FONT FACE="Times New Roman, serif">downloaden. </FONT> +</P> +<P><STRONG><FONT FACE="Times New Roman, serif">Beachte:</FONT></STRONG> +Du wirst <FONT FACE="Times New Roman, serif">ca. 200 MB an +komprimierten Sourcecode downloaden und solltest ca. 5Gb an freiem +Speicherplatz haben, um alles zu entpacken und zu builden.</FONT></P> +<H2><A NAME="section2"></A><A NAME="section-2"></A>2. OOo builden +</H2> +<H3><A NAME="section-2.1"></A>2.1. configure</H3> +<P><FONT FACE="Times New Roman, serif"><FONT SIZE=3>Der komplette +Buildprozess ist ziemlich kompliziert. Du hast erstmal die Wahl von +zwei Befehlen, obwohl es eigentlich nichts ausmacht beide +auszuführen:</FONT></FONT></P> +<P STYLE="margin-bottom: 0in"><BR> +</P> +<PRE> ./autogen.sh # the CVS version + ./configure # the packaged version</PRE><P> +<FONT FACE="Times New Roman, serif">Das wird wird herausfinden +welchen <SPAN STYLE="background: transparent">Snapshot-Zweig</SPAN> +du builden möchtest. Wenn du andere Ideen hast, benutze bitte +--with-tag Option, wie z.B. </FONT> +</P> +<PRE STYLE="margin-bottom: 0.2in">--with-tag=OOO_1_1_0</PRE><P> +<FONT FACE="Times New Roman, serif">für einen Vermächtniszweig +(="legacy branch").</FONT></P> +<P STYLE="margin-bottom: 0in"><BR> +</P> +<H3><A NAME="section-2.2"></A>2.2 download</H3> +<P><FONT FACE="Times New Roman, serif"><FONT SIZE=3>Nach der Zeit, in +der du dein System zu dem Stand gebracht hast, dass es alle +benötigten Pakete hat (mozilla, libart etc.), ist fast schon der +Zeitpunkt gekommen, den Sourcecode downzuloaden. Um das nach einem +erfolgreichen configure Befehl zu machen, schreibe:</FONT></FONT></P> +<PRE STYLE="margin-bottom: 0.2in"><FONT SIZE=3>./download</FONT></PRE><P> +<BR><BR> +</P> +<P><FONT FACE="Times New Roman, serif"><FONT SIZE=3>und warte[...]</FONT></FONT></P> +<P><BR><BR> +</P> +<P><A NAME="section-2.3"></A><FONT FACE="Times New Roman, serif"><FONT SIZE=4><B>make</B></FONT></FONT></P> +<P><FONT FACE="Times New Roman, serif">Nun kommt der Knackpunkt:</FONT> +</P> +<PRE STYLE="margin-bottom: 0.2in">make</PRE><P> +<FONT FACE="Times New Roman, serif">und vergesse nicht <Enter> +zu drücken. Gut möglich ist es auch, dass du die Ausgabe +protokollieren willst, also warum nicht</FONT></P> +<PRE STYLE="margin-bottom: 0.2in">make 2>&1 | tee /tmp/log</PRE><P> +.</P> +<H2><A NAME="section3"></A>3. OOo installieren</H2> +<P><FONT FACE="Times New Roman, serif">Das Ergebnis eines +ordentlichen Builds ist ein perfektes Installationspaket in</FONT></P> +<PRE STYLE="margin-bottom: 0.2in">build/$TAG/instsetoo/unxlngi4.pro/01/normal/</PRE><P> +<FONT FACE="Times New Roman, serif">oder ähnlich. Dann führe +zum Installieren das Setup-Programm von dort aus, in dem du z.B. </FONT> +</P> +<PRE STYLE="margin-bottom: 0.2in">/opt/OOInstall</PRE><P> +<FONT FACE="Times New Roman, serif">benutzt. Um das funktionsfähig +zu vollenden, musst du erst noch deine</FONT></P> +<PRE STYLE="margin-bottom: 0.2in">~/.sversionrc</PRE><P> +Datei ausführen.</P> +<P><BR><BR> +</P> +<P><FONT FACE="Times New Roman, serif">Nun da es schon mal +installiert ist, wollen wir auch gleich mal in die Stimmung kommen, +OOo zu hacken, indem wir den build-tree direkt auf das installierte +Abbild verweisen, sodass wir beim re-compilen eines +Code-Unterverzeichnisses, OOo einfach neu ausführen können. +Dies kann den Build/Test-Lauf um einige Zehntel schneller machen. Um +dies zu erreichen, schreibe:</FONT></P> +<PRE STYLE="margin-bottom: 0.2in">bin/linkoo /opt/OOInstall /opt/ooo-build/build/OOO_1_1_2</PRE><P> +<FONT FACE="Times New Roman, serif">, schaue auch bitte die <A HREF="#section5-9">Linker +Einschränkungen</A> an.</FONT></P> +<H2><A NAME="section4"></A>4. OOo ausführen</H2> +<P><FONT FACE="Times New Roman, serif">Nun gehe man in</FONT></P> +<PRE STYLE="margin-bottom: 0.2in">/opt/OOInstall/program</PRE><P> +<FONT FACE="Times New Roman, serif">und schreibe </FONT> +</P> +<PRE STYLE="margin-bottom: 0.2in">source ./ooenv</PRE><P> +<FONT FACE="Times New Roman, serif">das wird die (bash) Shell <FONT COLOR="#000000"><SPAN STYLE="background: transparent">darauf +einstellen, OOo direkt auszuführen</SPAN>.</FONT> Dann einfach</FONT></P> +<PRE STYLE="margin-bottom: 0.2in">soffice.bin</PRE><P> +<FONT FACE="Times New Roman, serif">. Dies ist besser als schlicht +soffice auszuführen oder ein "Wrapper-Skript", da es +nun ganz einfach ist den Fehlersuchprogramm anzuhängen:</FONT></P> +<P>gdb soffice.bin</P> +<P>. +</P> +<P><BR><BR> +</P> +<P><STRONG><FONT FACE="Times New Roman, serif">Beachte:</FONT></STRONG> +<FONT FACE="Times New Roman, serif">Benutze *nicht*: </FONT> +</P> +<PRE STYLE="margin-bottom: 0.2in">./soffice.bin</PRE><P> +<FONT FACE="Times New Roman, serif">was wegen unerklärten +Gründen nicht richtig funktioniert. </FONT> +</P> +<P><STRONG><FONT FACE="Times New Roman, serif">Beachte:</FONT></STRONG> +Du <FONT FACE="Times New Roman, serif">musst zuvor den auf OOo +basierten ooo-wrapper ausführen, sodass ~/.sversionrc ordentlich +eingestellt ist, ansonsten wird die soffice.bin zum GUI setup +Werkzeug verweisen. Tue:</FONT></P> +<PRE STYLE="margin-bottom: 0.2in">oowriter</PRE><P> +<FONT FACE="Times New Roman, serif">vor dem Start.</FONT></P> +<H2><A NAME="section5"></A>5. OOo hacken</H2> +<H3><A NAME="section-5.0"></A>5.1 Der erste Hack</H3> +<P><FONT FACE="Times New Roman, serif">Alsoo - wir haben OOo nun +gebuildet und ausgeführt, und wir wollen uns selbst nun +beweisen, dass es wirklich möglich ist, das Biest zu hacken. In +einem neuen Terminal machen wir also jenes:</FONT></P> +<PRE>cd build/$TAG +. ./LinuxIntelEnv.Set.sh +cd vcl</PRE><P> +<FONT FACE="Times New Roman, serif">Wie wärs nun mit einem Hack +in vcl/source/window/toolbox2.cxx? Ich würde vorschlagen einfach +mal ein</FONT></P> +<PRE STYLE="margin-bottom: 0.2in">nPos = 0</PRE><P> +<FONT FACE="Times New Roman, serif">irgendwo vor dem m_aItems.insert +in ToolBox::InsertItem( const ResId &rResId ...) hinzuzufügen. +Dann abspeichern.</FONT></P> +<P><FONT FACE="Times New Roman, serif">Noch in VCL, ja? Dann schreibe +'build debug=true'; warte darauf, dass der rollende Text stoppt; (5 +Sekunden?). Nun neu ausführen..</FONT></P> +<PRE STYLE="margin-bottom: 0.2in">soffice -writer</PRE><P> +<FONT FACE="Times New Roman, serif">Du solltest den Effekt +mitbekommen haben.</FONT></P> +<P><BR><BR> +</P> +<P><STRONG><FONT FACE="Times New Roman, serif">Beachte:</FONT></STRONG> +D<FONT FACE="Times New Roman, serif">ies stellt die Vorraussetzung, +dass du die vorigen Schritte befolgt hast, speziell das linkoo in +</FONT><A HREF="http://ooo.ximian.com/hackers-guide.html#section-3"><FONT FACE="Times New Roman, serif">Sektion +3</FONT></A><FONT FACE="Times New Roman, serif">.</FONT></P> +<P><STRONG><FONT FACE="Times New Roman, serif">Beachte:</FONT></STRONG> +<FONT FACE="Times New Roman, serif">Für simples ab-und-zumal +hacken kannst du "build" im Source Tree ausführen. +Führe "make" *nicht* im Hauptverzeichnis</FONT></P> +<PRE STYLE="margin-bottom: 0.2in">ooo-build/</PRE><P> +<FONT FACE="Times New Roman, serif">aus, oder alle Änderungen +können höchstwahrscheinlich weggeschmissen werden. Es macht +daher Sinn eine separate Kopie von </FONT> +</P> +<PRE STYLE="margin-bottom: 0.2in">build/OOO_1_1_2</PRE><P> +<FONT FACE="Times New Roman, serif">zu haben, schaue </FONT><A HREF="http://ooo.ximian.com/hackers-guide.html#section-10.4"><FONT FACE="Times New Roman, serif">hier</FONT></A><FONT FACE="Times New Roman, serif">, +um den Build schließlich wieder anzuordnen.</FONT></P> +<P><BR><BR> +</P> +<H3><A NAME="section-5.1"></A>5.2 Lese das Handbuch</H3> +<P><FONT FACE="Times New Roman, serif">Mit der Stärke von C++ +kommt die Fähigkeit sich selbst ins Knie zu schießen, +vergleiche </FONT><EM><FONT FACE="Times New Roman, serif">Holub, +Rules for C and C++ programming, McGraw-Hill, 95.</FONT></EM></P> +<P><FONT FACE="Times New Roman, serif">Der beste Weg sich für +die Herausforderung vorzubereiten, ist erst einmal die OOo +</FONT><A HREF="http://tools.openoffice.org/CodingGuidelines.sxw"><FONT FACE="Times New Roman, serif">Coding-Guidlines</FONT></A> +<FONT FACE="Times New Roman, serif">zu lesen und für alle, die +es nicht wissen, c'tor / d'tor sind die Abkürzungen für +constructor / destructor.</FONT></P> +<P><BR><BR> +</P> +<H3><A NAME="section-5.2"></A>5.3 Patche einsenden</H3> +<P><FONT FACE="Times New Roman, serif">Selten ist klar welches Modul +zu welchem Bugreport (Issuezilla) gehört. Ein möglichst +kurzer Weg dies herauszufinden, ist: </FONT> +</P> +<PRE>cvs status <somefile> | head + </PRE><P> +<FONT FACE="Times New Roman, serif">Das sollte eine +<SPAN STYLE="background: transparent"><FONT COLOR="#000000">'<SPAN STYLE="background: transparent">Archiv-Version</SPAN>(="repository +revision"):' </FONT></SPAN>Zeile geben, mit einem Pfad, dessen +zweiter Teil den Modulnamen verrät.</FONT></P> +<P><BR><BR> +</P> +<H3><A NAME="section-5.3"></A>5.4 Den <SPAN STYLE="background: transparent">Installer</SPAN> +hacken</H3> +<P><FONT FACE="Times New Roman, serif">Da das Installationsabbild das +ausführbare temporäre Setupabbild in </FONT><TT><FONT FACE="Times New Roman, serif">/tmp/sv001.tmp +löscht, müsstest du es dabei verhindern dies zu tuen. Führe +dazu bitte setup / install mit der -dontdeletetemp Option aus.</FONT></TT></P> +<P><BR><BR> +</P> +<H3><A NAME="section-5.4"></A>5.5 Andere Bereiche hacken</H3> +<P><FONT FACE="Times New Roman, serif">Wenn ein funktionierender +Installer vorliegt, ist der beste Weg den Hack zu integrieren, indem +du <TT>program/lib<EM>foo</EM>641li.so</TT></FONT> <FONT FACE="Times New Roman, serif">zu +der von dir gebuildeten Version <SPAN STYLE="background: transparent">symbolisch +verweist </SPAN>- höchstwahrscheinlich in:</FONT> +<TT><EM><FONT FACE="Times New Roman, serif">foo</FONT></EM><FONT FACE="Times New Roman, serif">/unxlngi4.pro/lib/ +-, dann sollten die Veränderungen eingearbeitet sein.</FONT></TT></P> +<P><FONT FACE="Times New Roman, serif">Als Beispiel sagen wir mal, du +willst "sal" (den System Abstraction Layer) hacken und du +hast OOO_STABLE_1 in /opt/OOInstall installiert, dann führe das +folgendes aus:</FONT></P> +<PRE>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 </PRE><P> +<BR><BR> +</P> +<H3><A NAME="section-5.5"></A>5.6 Dmake verstehen (man)</H3> +<P><FONT FACE="Times New Roman, serif">Während das Build-System +sehr ähnlich ist zu anderen Systemen, hat es jedoch trotzdem +noch seine besonderen Eigenheiten. Das gesamte Konzept besteht darin, +dass jedes Modul einzeln gebuildet wird und die kompilierten Dateien +in den </FONT><A HREF="http://www.openoffice.org/dev_docs/source/solver.html"><FONT FACE="Times New Roman, serif">Solver-Tree</FONT></A> +<FONT FACE="Times New Roman, serif">wandern.</FONT></P> +<P><FONT FACE="Times New Roman, serif">Jedes Modul selbst kompiliert +gegen die Headerdateien des Solvers, deshalb entstehen grundsätzlich +auch keine unnötigen Komplikationen.</FONT></P> +<P><BR><BR> +</P> +<UL> + <LI><P STYLE="font-style: normal"><FONT FACE="Times New Roman, serif"><I>built + </I>- Dieses Perl Skript solenv/bin/build.pl wird in Verbindung mit + prj/build.lst benutzt, um sicher zu gehen, dass jedes Modul das + gebraucht wird zuerst gebuildet wird.</FONT></P> + <LI><P STYLE="font-style: normal"><FONT FACE="Times New Roman, serif">deliver + - Dieses Perl Skript solenv/bin/deliver.pl installiert Headerdateien + und Bibliotheken in den Solver, wie in prj/d.lst beschrieben. + 'deliver' überprüft unter anderem, dass der Datumsstempel + jeder in den Solver kopierten Datei der gleiche ist wie im + Modulverzeichnis. </FONT> + </P> +</UL> +<H4><A NAME="section-5.5.1"></A>5.6.1 Standardverzeichnisse</H4> +<P><FONT FACE="Times New Roman, serif">Es gibt einige +Standardverzeichnisse, die in jedem OOo Modul vorhanden sind: </FONT> +</P> +<UL> + <LI><P STYLE="margin-bottom: 0in"><FONT FACE="Times New Roman, serif"><B>prj</B> + </FONT> + </P> + <UL> + <LI><P STYLE="margin-bottom: 0in"><FONT FACE="Times New Roman, serif"><I>build.lst</I> + — dies beschreibt die generierten Verzeichnisse, '^#' + Kommentare sind erlaubt, die Reihenfolge dieser Liste ist nicht von + Belangen, siehe <A HREF="#section5-6-2">Details</A>, <FONT COLOR="#000000">es + diktiert die Hauptoperationen von build</FONT><FONT COLOR="#ff0000">. + </FONT></FONT> + </P> + <LI><P STYLE="margin-bottom: 0in"><FONT FACE="Times New Roman, serif"><I>d.lst</I> + — diese Datei beschreibt den "<SPAN STYLE="background: transparent">Deliverprozess</SPAN>", + siehe </FONT><A HREF="#section5-6-3"><FONT FACE="Times New Roman, serif">Details</FONT></A><FONT FACE="Times New Roman, serif">. + </FONT> + </P> + </UL> + <LI><P STYLE="margin-bottom: 0in"><FONT FACE="Times New Roman, serif"><B>util</B> + — <SPAN STYLE="background: transparent"><FONT COLOR="#000000">die + Dateien dieses Verzeichnisses haben normalerweise die Aufgabe die + <SPAN STYLE="background: transparent">Bibliotheken </SPAN>für + jedes <SPAN STYLE="background: transparent">Untermodul</SPAN> in + eine größere Bibliothek zusammenzuführen, es + integriert dabei auch die gebrauchten System-Bibliotheken und + buildet die GUI Resourcen etc</FONT></SPAN><FONT COLOR="#ff0000">.</FONT> + Die gesamte Vorgehensweise ist im <I>makefile.mk</I> beschrieben. + Dies ist üblicherweise das letzte zu buildende Verzeichnis in + einem Projekt. </FONT> + </P> + <LI><P><FONT FACE="Times New Roman, serif"><B>inc</B> — + allgemeine Headerdateien sind normalerweise im 'inc' Verzeichnis zu + finden. Diese werden durch 'deliver' in den Solver kopiert (dabei + wird <I>prj/d.lst </I>benutzt). </FONT> + </P> +</UL> +<P><FONT FACE="Times New Roman, serif">Es gibt mehrere Dateiformate +die Build-spezifisch sind: </FONT> +</P> +<UL> + <LI><P STYLE="margin-bottom: 0in"><FONT FACE="Times New Roman, serif"><B>makefile.rc</B> + — diese Dateien sind alle nebensächlich und gebrauchen + keiner Erklärung.</FONT></P> + <LI><P><FONT FACE="Times New Roman, serif"><B>makefile.mk</B> — + diese hingegen sind die für jedes Modul wichtigen "dmake" + Dateien</FONT></P> +</UL> +<H4><A NAME="section5-6-2"></A><A NAME="section-5.5.2"></A>5.6.2 +build.lst</H4> +<P>Auf den ersten Blick sieht <I>build.lst</I> ein bißchen +<FONT COLOR="#000000">schaurig</FONT> aus: +</P> +<PRE>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</PRE><P> +<FONT COLOR="#000000">sodass wir uns also gleich ranmachen das ganze +Stück für Stück unter die Lupe zu nehmen, was uns dann +zeigen wird, dass es nicht so arg schlimm ist, wie es auf den ersten +Blick erscheinen mag.</FONT></P> +<P>Als aller erstes fällt auf, dass jede Listenzeile mit einem +'NULL'-String endet (man kann hier von einem Sentinel sprechen). +Außerdem verzeichnet jede Listenzeile über ein Kürzel +ganz am Anfang, was aber für uns als irrelevant zu bezeichnen +gilt. +</P> +<UL> + <LI><P STYLE="margin-bottom: 0in">Die allererste Zeile der Datei + enthält einen Doppelpunkt ':', dies beschreibt den Bestand, + dass das Projekt (vcl) von anderen Modulen abhängig ist. 'nas', + 'freetype', 'psprint' etc. müssen also zuvor gebuildet worden + sein. Dies ist wichtig für das Ineinandergreifen der + verschiedenen Projekte. + </P> + <LI><P STYLE="margin-bottom: 0in">Dann haben wir die eher + überflüssige Zeile mit 'usr1' [ zum Spaß ? ], + tatsächlich sind alle kommenden Zeilen nur gültig mit dem + speziellen 'nmake' String!</P> + <LI><P>Die nächste Zeile beschreibt projektinterne + Verzeichnisabhängigkeiten: + </P> + <PRE>[shortcut] [path to dir to build] nmake - [flags] [unique-name] [deps...] NULL +vc vcl\source\glyphs nmake - all vc_glyphs vc_unot NULL + </PRE><P> + <I>shortcut</I> wird funktional nicht benutzt, <I>flags</I> stellt + fest, auf welcher Plattform das Projekt gebuildet wird. + Normalerweise stehen die kurzen Plattformbezeichnungen: 'dnpum' 'u' + für Unix. Je höher das System, desto mehr wird 'all' + eingefügt.</P> + <P><I>unique-name</I> dies ist ein spezieller Name, der von anderen + Zeilen für interne Zusammenhänge gebraucht wird. <SPAN STYLE="background: transparent"><I>deps...</I> + variable Anzahl von Verzeichnissen in dieser Datei, die zuvor + gebuildet werden müssen.</SPAN></P> +</UL> +<P>Im Falle von vcl (="Visual Component Library") sehen wir +also, dass <I>vcl\source\unotypes </I>(vc_unot) noch vor +<I>vcl\source\glyphs</I> (vc_glyphs) gebuildet werden muss. Es ist +wirklich <B>wichtig </B>zu verstehen, dass die Reihenfolge der Liste +unwesentlich ist und statt eine simple klar-geordnete Liste, haben +wir eher ein komplexeres internes <FONT COLOR="#000000">Beziehungssystem, +das demzugrunde von anderen make-Konzepten abweicht. </FONT> +</P> +<P>Eine detailliertere Dokumentation findet man <A HREF="http://tools.openoffice.org/tools/build.html">hier</A> +</P> +<H4><A NAME="section5-6-3"></A><A NAME="section-5.5.3"></A>5.6.3 +d.lst</H4> +<P>d.lsts Syntax ist verständlicher als jene von build.lst, es +unterlässt einge Standardfunktionen, wie z.B. das Kopieren von +build.lst nach <I>inc/<module>/build.lst.</I></P> +<P>Eine Zeile hat die folgende Form: +</P> +<PRE>[action]: [arguments] +mkdir: %_DEST%\inc%_EXT%\external + </PRE><P> +die standardgemäße Kopiefunktion wird durchgeführt, +wenn '[action]:' weggelassen wird. Die typischen Ausführungen +sind <I>copy</I>, <I>mkdir</I>, <I>touch</I>, <I>hedabu</I>, <I>dos</I> +and <I>linklib</I>.</P> +<P>Speziell der 'hedabau' Befehl ist interessant, in der Weise, dass +es die Headerdateien beim Installieren kürzer werden lässt +(ansonsten ist es eigentlich nicht viel anders als das übliche +Kopieren). +</P> +<P>Während dieser Aktion werden verschiedene Macros verwendet, +manche davon sind:</P> +<UL> + <LI><P>%__SRC% - Distributionsverzeichnisname z.B. <I>unxlngi4.pro</I> + </P> + <LI><P>%_DEST% - absoluter Pfad zum Solver z.B. + <I>/opt/OpenOffice/OOO_STABLE_1/solver/641/unxlngi4.pro</I> + </P> +</UL> +<UL> + <LI><P>%_EXT% - <FONT COLOR="#000000">End-Versionsnummer bei + Aktualisierungen, üblicherweise benutzt für jedes + Unterverzeichnis im <SPAN STYLE="background: transparent">Hauptast</SPAN>("MasterWorkspace")</FONT></P> +</UL> +<P>Wenn du wirklich eine bestimmte Regel einführen willst (wie +z.B. impliziertes Verzeichniskopieren), dann wird dies dem folgenden +Schema entsprechen: +</P> +<PRE>..\%__SRC%\inc\sal\*.h %_DEST%\inc%_EXT%\sal\*.h + </PRE><P> +Achte darauf, dass Pfade relativ zum 'prj/' Verzeichnis sind. +</P> +<H3><A NAME="section-5.6"></A>5.7 <SPAN STYLE="background: transparent"><FONT COLOR="#000000">Schnelle +Iteration</FONT></SPAN></H3> +<P>Es gibt viele Wege zu schnellem <FONT COLOR="#000000"><SPAN STYLE="background: transparent">Entwicklungsfortschritt</SPAN>,</FONT> +der wohl beste Weg ist <A HREF="#section3">linkoo</A> zu benutzen, um +die Bibliotheken aus dem Installationspaket direkt in den Build-Tree +symbolisch zu verweisen. Dann kannst du auf einfache Art und Weise +Unterverzeichnisse "re-builden" und zwar indem du:</P> +<PRE STYLE="margin-bottom: 0.2in">build</PRE><P> +im Unterverzeichnis verwendest und soffice.bin neu ausführst. +</P> +<P>Nun kommen wir dann mal zum Sourcecode selbst..</P> +<H3><A NAME="section5-8"></A><A NAME="section-5.7"></A>5.8 Kann ich +<CODE>char * <FONT FACE="Times New Roman, serif">benutzen</FONT></CODE>?</H3> +<P><FONT COLOR="#000000">Eher dürftig</FONT>. OOo hat mindestens +sechs String-Wrapper, wobei den C Umsetzungen nur sehr geringe +Achtung geschenkt werden sollte:</P> +<UL> + <LI><P><CODE>rtl_String</CODE> - sal/inc/rtl/string.h<BR>"Normaler" + String mit ref-counting. <CODE>rtlstring->buffer</CODE> ist + hilfreich, wie auch <CODE>rtlstring->length</CODE>. Dieser String + ist schon umgewandelt zu einem bestimmten Charakterset, siehe + sal/inc/rtl/textenc.h - die einzigen interessanteren Fälle sind + <CODE>RTL_TEXTENCODING_UTF8 <FONT FACE="Times New Roman, serif">und + vielleicht noch</FONT> RTL_TEXTENCODING_ASCII_US</CODE> . Fühle + dich frei <CODE>rtlstring->buffer</CODE> als deinen beliebten C + <CODE>char * <FONT FACE="Times New Roman, serif">anzusehen</FONT></CODE>. + </P> + <LI><P><CODE>OString</CODE> - sal/inc/rtl/string.hxx<BR><CODE><FONT FACE="Times New Roman, serif">Der + <CODE>rtl_String</CODE> einfach als Klasse implementiert.</FONT></CODE> + Du kannst <CODE>ostring.pData</CODE> benutzen, um direkt an den + rtl_String zu gelangen. <CODE>OString</CODE> hat ganz sicher einige + nützliche Funktionen. + </P> + <LI><P><CODE>rtl_uString</CODE> - sal/inc/rtl/ustring.h<BR>"Normaler" + Unicode String, ähnlich wie rtl_String auch mit ref-counting. + Wie auch immer, dieser String kommt immer im UCS-2 enkodierten + Format, um mit Javas fraglicher Auswahl kompatible zu sein.</P> + <LI><P><CODE>OUString</CODE> - sal/inc/rtl/ustring.hxx<BR>Ein + rtl_uString <CODE><FONT FACE="Times New Roman, serif">als Klasse</FONT></CODE>. + Das ist der intern am häufigsten benutzte String um Daten + auszutauschen.</P> + <LI><P><CODE>String</CODE> - tools/inc/string.hxx<BR>Das ist ein + veralteter Typ, der unter den Namen 'UniString' fällt. Es hat + einige Einschränkungen wie ein rtl_uString <CODE><FONT FACE="Times New Roman, serif">innerhalb + einer Klasse</FONT></CODE>. + </P> +</UL> +<P>Da ja jeder richtige Programmierer <CODE>char *</CODE> UTF-8 +enkodierte Strings verwendet, muss jeglicher System-API Aufruf wie +z.B. 'printf' ein Chararray von <CODE>OUString</CODE> aus +konvertieren: +</P> +<PRE>static char * +gimme_utf8_please (const rtl::OUString &oustring) +{ + rtl::OString ostring; + + ostring = ::rtl::OUStringToOString (oustring, RTL_TEXTENCODING_UTF8); + return strdup (ostring.pData->buffer); +} + </PRE><P> +und hier in entgegengesetzter Richtung: +</P> +<PRE>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); +} + </PRE><P> +Wenn du einfach nur einen String für Fehlersuch-Zwecke schreiben +lassen willst, dann wirst du wahrscheinlich <A HREF="#printout">das</A> +hier haben.</P> +<H4><A NAME="section-5.7.2"></A>5.8.1 Strings mit GDB untersuchen</H4> +<P>Wir haben schon gesehen, dass OOo nicht die bescheidenen <CODE>char +*</CODE> Strings benutzt. Wenn du nun dachtest es wär schon +anstrengend genug Code zu schreiben, dann warte lieber ab bis wir +noch zum Debugging kommen. Glücklicherweise zeigen wir dir nun +wie du an Strings von gdb/dbx - die selbst nicht mit Unicode umgehen +- herankommst: +</P> +<UL> + <LI><P>vom CVS Zweig cws_srx645_ooo112fix1 aufwärts kann + </P> + <PRE STYLE="margin-bottom: 0.2in">(gdb) print dbg_dump(sWhatEver)</PRE><P> + benutzt werden, um den Inhalt eines + UniString/ByteString/rtl::OUString/rtl::OString's auf den Bildschirm + zu drucken, dabei ist der Typ bei der Fehlerbeseitigung des C++ + Codes egal. Siehe <A HREF="http://qa.openoffice.org/issues/show_bug.cgi?id=17295">iz17295</A> + für nähere Details. + </P> +</UL> +<P>Wenn das in deiner OOo Version noch nicht unterstützt wird, +gibts noch eine Alternative... +</P> +<UL> + <LI><P STYLE="margin-bottom: 0in">rtl_String: probier rum damit! + </P> + <LI><P STYLE="margin-bottom: 0in">String: Achte darauf, dass die + Deklaration das macro 'UniString' benutzt, um Leser von + tools/inc/string.hxx zu irritieren. Glücklicherweise können + wir leicht und locker ein String zu einem OUString konvertieren + ("casten"). + </P> + <LI><P STYLE="margin-bottom: 0in">OString: <I>p str->pData</I> + </P> + <LI><P>OUString, rtl_uString: (toller Tip von Kevin Hendricks) Der + schnellste und einfachste Weg den String auszuwerfen ist wie folgt: + </P> + <PRE> p *theString; # grab the length (2nd field) + x/<length>s theString->buffer</PRE><P> + für einen 20 Charakter-langen String wollen wir dann also + </P> + <PRE STYLE="margin-bottom: 0.2in">x/20s theString->buffer</PRE><P> + . Das sollte dann den String als Array aus Elementen des Typs Short + mit ASCII Werten sauber und fein in eine Rubrik schreiben.. Um + programmtechnisch einen OUString (or String) <FONT COLOR="#000000">zu + erhalten</FONT>: + </P> + <PRE><A NAME="printout"></A>::rtl::OString tmpStr = OUStringToOString (<I>MyOUString</I>, RTL_TEXTENCODING_UTF8); +fprintf (stderr, "String is '%s'\n", tmpStr.getStr());</PRE> +</UL> +<H3><A NAME="section5-9"></A><A NAME="section-5.8"></A>5.9 Linkoo +Einschränkungen</H3> +<UL> + <P STYLE="margin-bottom: 0in">Während Linkoo für sich + recht "leistungsfähig" ist, wird es durch die Art und + Weise wie OOo zusammengeflickt ist in seiner Stärke + eingeschränkt. Es gibt hierbei zwei Musterprobleme: + </P> + <UL> + <LI><P STYLE="margin-bottom: 0in">Sonderbares Verhalten beim Linken + - wenn du die Bibliothek symbolisch verweist, dann folgt es dem + Link während der Runtime und endet arg im Durcheinander.</P> + <UL> + <LI><P STYLE="margin-bottom: 0in">soffice.bin - muss bei jedem + <FONT COLOR="#000000">Enwticklungsdurchgang</FONT><FONT COLOR="#ff0000"> + </FONT>von desktop/unxlngi4.pro/bin/soffice kopiert werden, + ansonsten <FONT COLOR="#000000">läuft die Fehlersuche + durcheinander.</FONT> + </P> + <LI><P STYLE="margin-bottom: 0in">libcfgmgr2.so - muss jedes Mal + von configmgr/unxlngi4.pro/lib kopiert werden, ansonsten kann die + Konfiguration nicht richtig geladen werden. + </P> + </UL> + <LI><P STYLE="margin-bottom: 0in"><SPAN STYLE="background: transparent">Merkwürdiges + internes Bibliothekensystem</SPAN></P> + <UL> + <LI><P>Dateifilter haben Prüfungs-Code ("detection + code"), wie sc/source/ui/app/sclib.cxx (ScDLL::DetectFilter) + z.B., welches zu statischen Bibliotheken kompiliert, installiert + und dann zu libwrp in desktop/source/offwrp gelinkt wird. Um 'sc' + erneut zu builden, mache: + </P> + <PRE STYLE="margin-bottom: 0.2in"><A HREF="http://ooo.ximian.com/build">build</A> && <A HREF="http://ooo.ximian.com/deliver">deliver</A></PRE><P> + dann im desktop/source/offwrp Ordner tue: + </P> + <PRE STYLE="margin-bottom: 0.2in">touch wrapper.cxx && dmake.</PRE> + </UL> + </UL> +</UL> +<UL> + <UL> + <UL> + <PRE STYLE="margin-bottom: 0.2in"> </PRE> + </UL> + </UL> +</UL> +<H2><A NAME="section6"></A><A NAME="section-6"></A>6. OOo debuggen</H2> +<P>Dieses Kapitel setzt die Benutzung des GNU debuggers von der +Konsole her voraus.</P> +<H3><A NAME="section-6.1"></A>6.1 Mit Debugging-Symbolen builden</H3> +<P>OOo beinhaltet die Möglichkeit Debugging-Code pro Modul zu +integrieren, nämlich via den <TT>build debug=true</TT> Befehl in +jedem Modul. Unglücklicherweise ist dies jedoch nicht für +den Gebrauch des gesamten Projektes zu empfehlen und neben vitalen +Debugging-Symbolen werden auch Unmengen an "<SPAN STYLE="background: transparent">Assertions</SPAN>", +aufkommende Warnungen und verschiedene andere Cheks mit +eingeschlossen.</P> +<P>Wenn du deshalb also Debugging-Symbole für alles haben +willst, musst du mehrere Makefiles hacken um Debugging-Symbole +hinzuzufügen (sei gewarnt, dass dies die binaries zu ca. 1GB +anwachsen lässt und den vollen <FONT COLOR="#000000">Build-Tree +sogar zu 8GB), wie hier beschrieben:</FONT></P> +<PRE>--- 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)"=="" + </PRE><P> +Natürlich wird gdb recht sinnlos ohne Debugging-Symbole. Um den +Patch also einzubringen, kopiere das oben stehende nach /tmp/foo und +ins Hauptverzeichnis.</P> +<PRE>patch -p0 < /tmp/foo + </PRE><H3> +<A NAME="section-6.2"></A>6.2 <SPAN STYLE="background: transparent">Breakpoints</SPAN> +setzen</H3> +<P>Wegen dem relativ groben Außmaß an Fehlern mit gdb, +ist es sehr wahrscheinlich, dass das Benutzen von Breakpoints nicht +rein funktionieren wird, deshalb ist wohl die beste Lösung das +folgende:</P> +<PRE>gdb ./soffice +break main +run # don't forget the arguments here +# ... traps in main ... +break osl_readFile +continue + </PRE><P> +Offensichtlich wird dies niemals erfolgreich ablaufen, wenn der Code +in einer Bibliothek implementiert ist, welche durch <FONT COLOR="#000000">'dlopen' +später geladen wird, was auf die große Mehrheit des OOo +Sourcecodes zutrifft. Deshalb sollte man den Code beim Laden +abfangen, um dann erst den Breakpoint einzusetzen.</FONT></P> +<P><FONT COLOR="#000000"><SPAN STYLE="background: transparent">Um +dies zu machen, hau einen Breakpoint in osl_psz_loadModule rein und +nun leide!</SPAN></FONT></P> +<P>Als Alternative dazu, wenn du den Code instrumentalisieren kannst, +sollte es ziemlich einfach sein einfach #include <signal.h> +beizufügen und einen SIGSTOP irgendwo im code zu werfen, welcher +dann den Debugger aufspürt.</P> +<P><BR><BR> +</P> +<H3><A NAME="section-6.3"></A>6.3 Wir beginnen immer am Anfang!</H3> +<P>Wir starten mal mit einem sal Wrapper in 'main', der +vcl/source/app/svmain.cxx (SVMain) anspricht.<FONT COLOR="#ff0000"> +</FONT><FONT COLOR="#000000">Main wird durch pSVData->mpApp +ausgelöst, aber pSVData ist inline</FONT>. Um dies zu +auszutesten, benutze die globale Variable pImplSVData. Z. B.:</P> +<PRE STYLE="margin-bottom: 0.2in"> p pImplSVData->maAppData</PRE><P> +Diese 'Main' Methode ist typicherweise in desktop/source/app/app.cxx +. +</P> +<H3><A NAME="section-6.4"></A>6.4 Strings untersuchen</H3> +<P>Der C-Char-Array Typ (den gdb anzeigen kann) wird bei +objekt-orientiertem Programmieren durch das <FONT COLOR="#000000">"Wrappen"</FONT> +von unzähligen verschiedenen Klassen vermieden, da gdb diese +Klassen naturell nicht versteht. Schlimmer noch, in vielen Fällen +ist es besonders schwer sogar einfach nur den String zu drucken - +eine der Konsequenzen von Sun's Strategie mit ucs-2 Enkodierung +fortzufahren. Es gibt dabei neben veränderbaren auch +unveränderbare Strings.</P> +<P>Bitte siehe dir <A HREF="#section5-8">Sektion 5.8</A> an, um zu +sehen wie man in OOo mit Strings um gehen sollte, Debugging Tips sind +dafür auch dabei.</P> +<H3><A NAME="section-6.5"></A>6.5 Die Build-Abfolge auf die Reihe +bekommen</H3> +<P>Die Build-Abhängigkeiten der Module sind nicht sehr eindeutig +und einfach, um einen sauberen Build hinzubekommen. Wenn du 'build' +in einem Modul schreibst, wird erstmal prj/build.lst analysiert, wie +neon/prj/build.lst zum Beispiel..</P> +<PRE>xh neon : soltools external expat NULL + </PRE><P> +dies macht klar, dass 'soltools', 'external' und 'expat' (mit +Geduld!) vorher noch gebuildet werden und danach zugestellt +("deliver") werden müssen, bevor 'neon' erstmal +gebuildet werden kann. Manchmal kommt es vor, dass diese Regeln +gebrochen werden und eine Weile vergeht, in der sowas nicht bemerkt +wird. Deshalb ist Vorsicht geboten! +</P> +<H3><A NAME="section-6.6"></A>6.6 Es crasht, aber nur in gdb</H3> +<P>Was für ein Spaß das ganze ist - <SPAN STYLE="background: transparent">du +hast im Installationsbaum desktop/unxlngi4.pro/bin/soffice zu +soffice.bin verwiesen, oder nicht?!</SPAN> Das funktioniert ja auch +ganz fein, wenn du es einfach ausführst. Aber es scheint, dass +gdb den symbolischen Link entpackt und einen regulären Pfad als +argv[0] sendet, was unglücklicherweise das Suchen nach dem +binären Pfad auswirkt, sodass es also den Hauptfad des Programms +als opt/OpenOffice/OOO_STABLE_1/desktop/unxlngi4.pro/bin zuweist und +nun dort nach applicat.rdb (nur als Beispiel) am Suchen ist. Es ist +deswegen auch klar wie Klosbrühe, dass es keine Setup +Informationen findet <FONT COLOR="#000000">und der Build-Prozess +irgendwo - ganz weit entfernt - in der Prärie ausstirbt.</FONT></P> +<H3><A NAME="section-6.7"></A>6.7 Es crasht, "stirbt" aber +nicht</H3> +<P>Wegen einigen Gründen werden Signalhandler aufgespürt, +und das Leben kann dann ganz schön verwirrend werden, deshalb +ist es für Entwickler durchaus gut etwas ähnliches, wie +unten beschrieben, zu integrieren: +</P> +<PRE>--- 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;</PRE><H3> +<A NAME="section-6.8"></A>6.8 Ich kann den Code im Fehlerprotokoll +nicht finden</H3> +<P>Manche Methoden haben eine spezielle Verbindung(=linkage), sodass +sie dann in Callbacks benutzt werden können.</P> +<P>Diese haben typicherweise die Präfix 'LinkStub', such deshalb +am besten für das letztere in einer Freitext-Suche:</P> +<PRE> IMPL_LINK( Window, ImplHandlePaintHdl, void*, EMPTYARG ) + </PRE><P> +Dies bildet dann die 'LinkStubImplHandlePaintHdl' Methode. +</P> +<H3><A NAME="section-6.9"></A>6.9 Wie kann ich die Dateien der +Fehlersuche erneut builden?</H3> +<P>Beim Benutzen von gdb kommt es oft vor, dass man es sich nicht +leisten kann ewig lang zu warten (oowriter Modul Kompilierung wäre +so ein Fall). Deswegen haben wir ein kleines Perl Skript geschrieben, +mit dem du Klassen-Namen und/oder Methoden - in die du interessiert +bist - vom Kellerspeicher ("stack") ausschneiden und +einfügen kannst, und dann wird das Perl-Hilfswerkzeug nur diese +Strings antasten ("touch"), um einen schnelleren und +einfacheren Build erfolgreich hinzulegen. Hier ist ein typischer +Ablauf von Fehlersuche und -beseitigung:</P> +<PRE> 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 + </PRE><P> +Demzufolge werden alle Dateien, die sich auf SfxMedium beziehen oder +irgendwas davon implementieren angetastet und mit Debugging-Symbolen +neu gebuildet.</P> +<P><BR><BR> +</P> +<H3><A NAME="section-6.10"></A>6.10 Wie kann ich alle Dateien eines +Ordners builden?</H3> +<P>Wenn du schlicht und weg den code in deinem aktuellen +Arbeitsverzeichnis kompilieren willst, dann verwende den killobj +dmake Befehl, um alle bereits existierende Objektdateien zu löschen:</P> +<PRE> dmake killobj + dmake + </PRE><H3> +<A NAME="section-6.11"></A>6.11 Es crasht immer in sal_XErrorhdl</H3> +<P>Huch, dann bist du ein Opfer von asynchronem (oder einfacher: +"one-way") X Fehlerreport, das</P> +<PRE STYLE="margin-bottom: 0.2in">export SAL_SYNCHRONIZE=1</PRE><P> +wird jegliche "X-Verkehrweichen" auf synchron stellen, und +den Fehler mit dem Benennen der Methode ausspucken. Es wird OOo auch +um einiges langsamer machen und das OOo Zeitsystem umstellen. +</P> +<H3><A NAME="section-6.12"></A>6.12 Stillschweigend schlägt es +Fehl beim Importieren meiner Word Datei</H3> +<P>Unser Caolan schlägt hier vor, Stopppunkte (fast schon +Schifffahrt-mässig mit drei "f" ;) ) oberhalb und +unterhalb von SwWW8ImplReader::LoadDoc in ww8par.cxx einzufügen, +und zu gehe sicher, dass das Dokument so weit geht wie der +Importfilter.</P> +<P>Ein gemütlicher Platz für einen Stopppunkt wäre bei +SwWW8ImplReader::ReadPlainChars, wo du ganze Brocken an Text (wie sie +eingelesen werden) sehen kannst. Eine Alternative wäre auch +SwWW8ImplReader::AppendTxtNode für jeden eingefügten +Paragraph.</P> +<P><BR><BR> +</P> +<H3><A NAME="section-6.13"></A>6.13 Wie benutze ich die +<SPAN STYLE="background: transparent">Debug-Konsole?</SPAN></H3> +<P>OOo beinhaltet eine ziemlich deftige Infrastruktur; seht <A HREF="http://ooo.ximian.com/images/debug-window.png">hier</A> +selbst. Bedauerlicherweise ist das <SPAN STYLE="background: transparent">Durchsetzen</SPAN> +nicht ganz so einfach. Zuerst einmal geht nichts davon in einen +offiziellen Produkt-Build, sodass wir also dazu gezwungen sind einige +OOo Kernstücke neu zu builden. Und schließlich sollten wir +linkoo neu ausführen, um diese neuen Builds in unser Paket +einzubinden.</P> +<P>Kreiere eine Umgebungsvariable (="environment variable"), +ich nenn sie hier LinuxIntelEnv.Set.debug: +</P> +<PRE>TMPFILE=~/.Env.Set.debug + +# Purge .pro bits +sed 's/\.pro//g' LinuxIntelEnv.Set.sh > $TMPFILE +. $TMPFILE +rm $TMPFILE + +# Clobber product parts +unset PRODUCT PROSWITCH PROFULLSWITCH </PRE><P> +Nun tue</P> +<PRE STYLE="margin-bottom: 0.2in">source ./LinuxIntelEnv.Set.debug</PRE><P> +, dies wird deine Umgebung für einen<SPAN STYLE="background: transparent"> +<FONT COLOR="#000000">Build</FONT><FONT COLOR="#ff0000"> </FONT>erschaffen</SPAN></P> +<PRE STYLE="margin-bottom: 0.2in">cd vcl; build dbgutil=true --all linkoo </PRE><P> +nun führe OOo aus und wenn es gerade voll im Arbeitsprozess ist, +drücke <Alt>-<Shift>-<Control> 'D' in +genannter Reihenfolge. Das sollte ein Popup-Debugging-Fenster zum +Erscheinen bringen. Die Fehlersuch-Optionen sind anschließend +in die dbgsv.init Datei gespeichert für den nächsten +Durchlauf. Du kannst den Ort dessen mit</P> +<PRE STYLE="margin-bottom: 0.2in">export DBGSV_INIT=$(HOME)/.dbgsv.init</PRE><P> +kontrollieren, leider handelt es sich hier um eine binäre Datei</P> +<H3><A NAME="section-6.14"></A>6.14 Excel +<SPAN STYLE="background: transparent">Interoperabilitäts</SPAN>-Debugging</H3> +<P>Das ist ganz einfach: Editiere sc/source/filter/inc/biffdump.hxx, +definiere EXC_INCL_DUMPER mit dem Wert 1 und dann builde 'sc' erneut. +<SPAN STYLE="background: transparent"><FONT COLOR="#000000">Hinzuzufügen +wäre noch sc/source/filter/excel/biffrecdumper.ini zu xxx zu +kopieren</FONT>.</SPAN> Dann führe +</P> +<PRE STYLE="margin-bottom: 0.2in">soffice.bin foo.xls</PRE><P> +aus und und voila es sollte eine foo.txt mit Debugging-Informationen +erstellt worden sein. Wenn du nichts erhalten haben solltest, dann +kannst du die sc-biffdump.diff <A HREF="http://qa.openoffice.org/issues/show_bug.cgi?id=25430">hier</A> +finden. +</P> +<H2><A NAME="section7"></A><A NAME="section-7"></A>7. Patche +bereitstellen</H2> +<P><BR><BR> +</P> +<H3><A NAME="section-7.1"></A>7.1. Diff Tool</H3> +<P>Wende diff immer im standardgemäßen 'cvs -z3 diff -u' +an, da dies die am einfachsten lesbaren diff-Dateien erstellt.</P> +<P><BR><BR> +</P> +<H3><A NAME="section-7.2"></A>7.2. Kommunikation</H3> +<P>Bevor man einen eigens ausgearbeiteten <FONT COLOR="#000000">Fix +(für einen Programmfehler)</FONT> implementiert, ist es ratsam +sich mit dem ein oder anderen Entwickler vorher darüber zu +unterhalten. Einer der besten Wege mit anderen Entwicklern in Kontakt +zu treten ist an <A HREF="mailto:dev@openoffice.org">dev@openoffice.org</A> +zu schreiben, oder im <FONT COLOR="#000000">channel #openoffice.org</FONT> +auf dem IRC Server: irc.freenode.net (Port: 6667) Ausschau zu halten. +IRC ist ein ziemlich stupides Kommunikationsmedium, aber es ist immer +noch viel besser als gar keine Kommunikation. Schaue <A HREF="http://ooo.ximian.com/name-account.html">hier</A> +nach, um zu erfahren, wer wer ist im channel. +</P> +<P><BR><BR> +</P> +<H3><A NAME="section-7.3"></A>7.3. ooo-build Patchsystem</H3> +<P>Schaue <A HREF="http://ooo.ximian.com/ooo-build.html#section-2.2">hier</A> +nach, um mehr über unsere <FONT COLOR="#000000">Patch-Struktur</FONT> +zu erfahren.</P> +<P><BR><BR> +</P> +<H3><A NAME="section-7.4"></A>7.4 Programmfehler mitteilen</H3> +<P><A HREF="http://ooo.ximian.com/bug.html">Hier</A> kannst du unsere +mildere Version des OpenOffice IssueZilla Systems sehen und beruhigt +benutzen :-).</P> +<P>Da wir oftmals die Hauptperson eines Moduls durch das Checken des +ADMIN_FILE_OWNER Tags herausbekommen können, haben wir dafür +extra ein kleines Tool für den ooo-build eingebaut: +</P> +<P>bin/owner <Dateiname> hilft dir dabei, wem du bezüglich +eines bestimmten Moduls e-mailen solltest. Es ist es in jedem Fall +Wert bei sehr spezifisch einzuordnenden Programmfehlern mit dieser +Person in Kontakt zu treten.</P> +<P><BR><BR> +</P> +<H2><A NAME="section8"></A>8. Sonstige Tipps</H2> +<P><BR><BR> +</P> +<H3><A NAME="section-8.1"></A>8.1. Wie stelle ich eine Verbindung mit +CVS Account her?</H3> +<P>Über die sichere SSH Methode. Dieser Abschnitt beschreibt die +Benutzung von CVS Accounts für den offiziellen OpenOffice.org +up-stream Server, ooo-build Accounts werden <A HREF="http://ooo.ximian.com/ooo-build.html#section-2.5.1">anders</A> +behandelt. Siehe auch i7270 im OOo Issuezilla. Sobald du den Account +hast, kannst du den CVS Server etwa in dieser Art <SPAN STYLE="background: transparent">"tunneln"</SPAN>:</P> +<PRE><FONT COLOR="#000000"><SPAN STYLE="background: transparent">ssh -f -2 -P -L 2401:localhost:2401 tunnel@openoffice.org sleep 1400 < /dev/null > /dev/null</SPAN></FONT> +<FONT COLOR="#000000"><SPAN STYLE="background: transparent"> </SPAN></FONT></PRE><P> +<FONT COLOR="#000000"><SPAN STYLE="background: transparent">Dann +kannst du deinen CVSROOT auf-deine-Festplatte-zeigend wechseln, da +dies ja der Ausgangspunkt des Tunnels ist:</SPAN></FONT></P> +<PRE><FONT COLOR="#000000"><SPAN STYLE="background: transparent">:pserver:cj@localhost:/cvs</SPAN></FONT> +<FONT COLOR="#000000"><SPAN STYLE="background: transparent"> </SPAN></FONT></PRE><P> +<FONT COLOR="#000000"><SPAN STYLE="background: transparent">Dein +Account Name und Passwort werden dieselben sein, wie im +openoffice.org Mitgliedsportal. Log dich ein und du wirst schnell +erkennen, dass du deine CVS Einstellungen zum neuen Server migrieren +musst. Das folgende sollte gut funktionieren: </SPAN></FONT> +</P> +<PRE STYLE="margin-bottom: 0.2in"><FONT COLOR="#000000"><SPAN STYLE="background: transparent">bin/re-root /path/to/checkout ":pserver:<account-name-here>@localhost:/cvs"</SPAN></FONT></PRE><P> +<FONT COLOR="#000000"><SPAN STYLE="background: transparent">Um etwas +direkt einzubinden, brauchst du natürlich mehrere +Projektprivilegien - und nebenbei musst du noch gegen die Bürokratie +ankämpfen :-).</SPAN></FONT></P> +<H3><A NAME="section-8.2"></A>8.2 patch / diff Benutzung</H3> +<P><FONT COLOR="#000000">patch/diff sind wunderbare Werkzeuge, doch +leider kommt es gar nicht mal so selten vor, dass wir Menschen Daten +angeben, die diese total durcheinander bringen; ein wirres "Klamaust" +entsteht als Folge.</FONT><FONT COLOR="#ff0000"> </FONT><FONT COLOR="#000000">Hier +sind ein paar Tricks, um dieses Durcheinander zu ordnen: </FONT> +</P> +<UL> + <LI><P STYLE="margin-bottom: 0in">Wenn generell unsicher, führe + patch mit der --dry-run Option aus, der dann anspringende Prozess + wird so erscheinen als verrichte er den Patch, tatsächlich wird + aber nichts repariert ("gepatcht"). (Trotz einiger + Nebenwirkungen, kann dieses "Simulieren" in etlichen + Situationen sehr hilfreich sein)</P> + <LI><P STYLE="margin-bottom: 0in">In den meisten Situationen + solltest du patch -p0 benutzen. Die 0 steht für die Anzahl der + Pfadelemente, die vom Anfang des Dateipfades - wo diff hinzeigt - + abgeschnitten wird.</P> + <LI><P STYLE="margin-bottom: 0in">Wenn du es durcheinander bringst, + und schon die Hälfte des Patches angelegt hast und du willst + mit einem sauberen Patch wieder von vorne beginnen, dann lösche + entweder die Dateien und aktualisiere cvs, oder patche von neuem mit + der '-R' Option, <FONT COLOR="#000000">um den Spieß (der Patch + Prozess ist hier gemeint) umzudrehen.</FONT></P> + <LI><P>Manchmal macht diff das Lesen der Patches schwerer, wenn + viele Lücken("white-space")-Veränderungen + zwischen den Modulen vorhanden sind. Der <FONT COLOR="#000000">Bitschalter + ("flag")</FONT> '-w' zum cvs diff macht das ganze hierbei + um einiges leichter.</P> +</UL> +<H3><A NAME="section-8.3"></A>8.3 Make clean</H3> +<P>Schreib einfach <I>dmake clean</I> im Hauptverzeichnis. In alten +Versionen, die noch über kein HEAD verzeichneten, war kein +allgemeines 'clean' Ziel, sodass man stattdessen etwas wie in der +folgenden Art tuen musste: +</P> +<PRE STYLE="margin-bottom: 0.2in">find -name 'unxlngi4.pro' -exec rm -Rf {} \;</PRE><H3> +<A NAME="section-8.4"></A>8.4 CVS setup</H3> +<P><FONT COLOR="#000000">Um die Bandbreite voll auszunutzen, +generiere vernünftige .diffs als Standard und folge dem Trend, +du brauchst das in deiner ~/.cvsrc. </FONT> +</P> +<PRE>cvs -z3 -q +diff -upN +update -dP +checkout -P +status -v </PRE><H3> +<A NAME="section-8.5"></A>8.5. Headerdateien zum Build integrieren +</H3> +<P>Die Integration von neuen Headerdateien in den Build Prozess ist +ziemlich umständlich. Um Headerdateien unter external/ +einzubringen, gehe ganz sicher, dass diese dann auch in +external/prj/d.lst aufgelistet sind, sodass sie beim Builden in das +solver/641/unxlngi4.pro/inc/external Verzeichnis kopiert werden.</P> +<H3><A NAME="section-8.6"></A><FONT COLOR="#000000">8.6. Beim Hacken +die richtige Datei finden</FONT></H3> +<P><FONT COLOR="#000000">Einen Programmfehler zu beheben, oder +anderes, kann schon einige Zeit durch den OOo Dateiendschungel in +Anspruch nehmen. Oft gibt es einen Verweis zu einem GUI Element in +unmittelbarer Nähe, wo du gerade suchst. Finde also so einen +String und suche mit <A HREF="http://ooo.ximian.com/lxr"><FONT COLOR="#000080">LXR</FONT></A><FONT COLOR="#000000">'s +<B>Text</B> Suche, das sollte dann einen Identifier zum String +enthüllen, wie z.B. SID_AUTOFORMAT oder FN_NUM_BULLET_ON. +Nachdem du diesen herausgefunden hast, starte eine neue Suchanfrage +und du wirst die Benutzung, oder sogar Definition/Deklaration des +betreffenden Identifiers finden. </FONT></FONT> +</P> +<H2><A NAME="section9"></A>9. Nützliche Links</H2> +<H3><A NAME="section-9.1"></A>9.1 www.openoffice.org</H3> +<P>Während das meiste des openoffice.org Portals nicht wirklich +Hacker-orientiert ist, gibt es trotzdem einiges an <A HREF="http://www.openoffice.org/documentation.html">Dokumentation</A> +für das Thema, du musst nur danach suchen. Die +<A HREF="http://tools.openoffice.org/">Tools-Projektseite</A> +schließt z.B. das richtige Kompilieren und Builden mit +verschiedenen Compilern auf verschiedenen Plattformen ein.</P> +<P><A HREF="http://www.ooodocs.org/">ooodocs.org</A> ist zwar nun +seit einiger Zeit ein wenig veraltet, bietet jedoch trotzdem einiges +an nennenswerten Informationen.</P> +<P>Persönlich kann ich das <A HREF="http://www.oooforum.org/">oooforum</A> +empfehlen, eines der wohl aktivsten Support-Forums im OpenSource +Bereich.</P> +<P>Andere verwandte Seiten sind: <A HREF="http://ooodi.sourceforge.net/">OOODI</A> +ein Gtk+ Bibliotheken Installierer. <A HREF="http://ooextras.sourceforge.net/">OOExtras</A> +bietet Templates, Macros und Clip Art. <A HREF="http://ooqstart.sourceforge.net/">Quickstart +applet</A> für GNOME (und <A HREF="http://segfaultskde.berlios.de/index.php?content=oooqs">KDE</A>). +<A HREF="http://dict.progbits.com/">Dictionaries & Docs</A> von +Kevin Hendricks. +</P> +<P>Seit kürzerer Zeit - genauer genommen seit Sun versprach eine +neue CWS-Regelung zu erschaffen, um es für außenstehende +einfacher zu machen ein bestimmtes Feature für OOo zu entwickeln +- gibt es auch den <A HREF="http://eis.services.openoffice.org/EIS2/servlet/GuestLogon">EIS-Service</A>, +in dem CWSs (Plural !) organisiert werden können. Für +nähere Informationen, kann ich nur die speziellen Präsentationen +der OOo Konferenz 2004 empfehlen.</P> +<H3><A NAME="section-9.2"></A>9.2 Patch Archiv</H3> +<P>Während viele verschiedene Versionen von OOo produziert +werden, sind viele Projekte in der letzten Zeit mit eigenen +beeindruckend großen Patch-Zusammenstellungen für OOo +hervorgekommen. +</P> +<P><BR><BR> +</P> +<UL> + <LI><P STYLE="margin-bottom: 0.16in"><A HREF="http://ooo.ximian.com/">Ximian</A>s + OOo Patche and Build-Werkzeuge / Snapshots sind als <A HREF="http://ooo.ximian.com/packages">Pakete</A> + oder <A HREF="http://ooo.ximian.com/patches">Patche</A> verfügbar.</P> + <LI><P STYLE="margin-bottom: 0.16in"><A HREF="http://www.debian.org/">Debian</A>s + hilfreiche OOo <A HREF="http://www.linux-debian.de/openoffice/">Seite</A>, + mit diversen Patchen. Und Debians <A HREF="http://cvs.debian.org/oo-deb/debian/?cvsroot=debian-openoffice">CVS</A>. + </P> + <LI><P STYLE="margin-bottom: 0.16in"><A HREF="http://www.linux-mandrake.com/">Mandrake</A>s + OOo <A HREF="http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/SPECS/OpenOffice.org/">Patch + Archiv</A>. + </P> + <LI><P STYLE="margin-bottom: 0.16in"><A HREF="http://www.freebsd.org/cgi/cvsweb.cgi/ports/editors/openoffice/#dirlist">FreeBSD</A>s + OOo <SPAN STYLE="background: transparent">Port-Patche</SPAN>. + </P> + <LI><P STYLE="margin-bottom: 0.16in">Red Hats .spec Datei (basierend + auf Mandrake) ist auch Wert zu lesen: von ihrer <A HREF="http://rawhide.redhat.com/pub/redhat/linux/rawhide/SRPMS/SRPMS/openoffice-1.0.1-6.src.rpm">SRPM</A> + Seite</P> +</UL> +<UL> + <LI><P STYLE="margin-bottom: 0.16in">Leute, die OOo lokalisieren + wollen, können diese <A HREF="ftp://ftp.linux.cz/pub/linux/people/pavel_janik/OpenOffice.org_1.0.1_CZ/build-13/build/Patches">Patche</A> + von Pavel Janik studieren. + </P> +</UL> +<H2><A NAME="section10"></A><A NAME="section-10"></A>10 (F)AQ</H2> +<P>Warum (F)..? Nunja, der gute Michael hat sich die folgenden Fragen +eher selbst gestellt.</P> +<H3><A NAME="section-10.1"></A>10.1 Wieso enthalten <SPAN STYLE="background: transparent">Zweignamen, +</SPAN>wie 'mws_srx644', ungerade Zahlen?</H3> +<P>Theoretisch erhöht sich die Nummer wöchentlich und da +wöchentlich "Freezes" vollzogen werden, gibt es auch +wöchentliche Solver und Entwicklungsumgebungen. Wie auch immer, +seit kürzester Zeit nimmt das Auskristallisieren eines einzigen +Buildes mehr Zeit als eine Woche in Anspruch - das führt dann +zum Dilemma der gemischten alphanumerischen "Versionstags". +Das <SPAN STYLE="background: transparent">'mws' steht für +'Master Workspace'.</SPAN></P> +<P><BR><BR> +</P> +<H3><A NAME="section-10.2"></A>10.2 Wieso wird Java unbedingt für +einen Build gebraucht ?</H3> +<P>Essenziell sieht es so aus, als seien, neben unterschiedlichen +anderen Services, eine Menge an XML Dateien an der +Komponentenregistration beteiligt. Es scheint so zu sein, dass dieser +Prozess am einfachsten mit Java zu vollziehen ist. Hinzu kommt, dass +Java effizient während der Run-Time benutzt werden kann.</P> +<P>Von <SPAN STYLE="background: transparent">"Tag" +</SPAN>SRC680_m44 an gibt es nun jedoch eine <A HREF="http://www.openoffice.org/issues/show_bug.cgi?id=28773">Alternative</A> +(geschrieben in Python), um das Problem des Analysierens der XML +Dateien und hauptsächlich ihrer Registration zu addressieren, +sodass es also möglich sein sollte nach m44 den Build ohne Java +hinzubekommen.</P> +<P><BR><BR> +</P> +<H3><A NAME="section-10.3"></A>10.3 Was zum Teufel ist mit [t]csh +los?</H3> +<P>Ganz einfach, csh funktioniert schlicht und einfach nicht richtig. +"Warum?" ist natürlich die große Frage und +soweit ich es weiß hängt es mit der speziellen Art +zusammen, wie die Piping-Befehle für stdin verlaufen, nämlich +ganz anders als von tty ausgehend:</P> +<PRE STYLE="margin-bottom: 0.2in">echo 'echo #define DLL_NAME "libsch641li.so" >./foo.hxx' | /bin/tcsh -s</PRE><P> +Das ganze schlägt normalerweise Fehl, wobei es beim direkten +Schreiben in die Shell jedoch funktioniert,</P> +<PRE STYLE="margin-bottom: 0.2in">tcsh -fc 'echo #define DLL_NAME "libsch641li.so" >./foo.hxx'</PRE><P> +bringt das erwünschte Ergebnis. Siehe auch <A HREF="http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/">csh</A>. +</P> +<H3><A NAME="section-10.4"></A>10.4 Ich habe gerade versucht den +Build <SPAN STYLE="background: transparent">woanders zu lokalisieren, +wieso schlägt es nun Fehl </SPAN>?</H3> +<P>Die verblüffende Antwort ist..... du musst +</P> +<PRE STYLE="margin-bottom: 0.2in">bin/relocate /path/to/new/build</PRE><P> +ausführen. Eine andere Antwortweise wäre um einiges länger: +</P> +<P>Wenn davon ausgegangen wird, dass du die nötigen Dinge neu +konfiguriert hast (auch LinuxIntelEnv.Set wird Rumbasteln der Pfade +brauchen und in die Shell reimport werden müssen) - dann liegt +das Problem wohl an den absoluten Pfaden, die vor allem in '.dpc*' +vorkommen. Versuche: +</P> +<PRE>find -name '*.dpc*' -exec rm {} \; + </PRE><P> +Der stlport schwächelt in einigen Dingen, sodass du also auch +'stl_gcc.h' innerhalb des solver/ Verzeichnisses editieren und die +dortigen beiden Pfad-Erwähnungen ersetzen musst (siehe +inc/stl/config/stl_gcc.h). +</P> +<H3><A NAME="section-10.5"></A>10.5 CVS sagt 'Fatal Error aborting. +[acc] no such user', wieso das denn jetzt ?</H3> +<P>Während es natürlich möglich ist, dass dein +Username nicht registriert ist, meint es oftmals jedoch dass deine +~/.cvspass Datei verschwunden ist und/oder, dass du dich nicht +eingeloggt hast. cvs login, daraufhin wiederhole den Befehl.</P> +<H3><A NAME="section-10.6"></A>10.6 Was habe ich unter '.pro' in +'unxlngi4.pro' zu verstehen ?</H3> +<P><I>Pro</I>duct - ist das nicht offensichtlich? :-) +</P> +<H3><A NAME="section-10.7"></A>10.7 Wie ist OpenOffice intern +aufgebaut ?</H3> +<P><IMG SRC="images/layers.png" NAME="Graphic1" ALT="Abstraction Layers" ALIGN=BOTTOM WIDTH=485 HEIGHT=330 BORDER=0> +</P> +<H3><A NAME="section-10.8"></A>10.8 <SPAN STYLE="background: transparent"><FONT COLOR="#000000">Wie +nehme ich einen <SPAN STYLE="background: transparent">Screenshot</SPAN> +von OOo auf </FONT></SPAN>?</H3> +<P>Manche konventionelle Screenshot Programme bekommen keine scharfen +Bilder auf die Reihe, weil OOo manche recht komische Dinge mit den X +Resourcen anstellt. ImageMagicks 'import' sollte jedoch seinen Zweck +erfüllen, benutze: +</P> +<PRE STYLE="margin-bottom: 0.2in">import foo.png</PRE><P> +von der Konsole, oder stattdessen</P> +<PRE STYLE="margin-bottom: 0.2in">sleep 2; import -window root foo.png</PRE><P> +. Es sei denn du willst deine "Welt" klein aussehen lassen, +solltest du die "Toolbar icons" vorher auf groß +stellen, versteht sich.</P> +<H3><A NAME="section-10.9"></A>10.9 Meine prefix Option beinhaltet +"BUILD", wieso schlägt der Build Fehl?</H3> +<P>Das hängt wieder mal mit unserem stlport zusammen, diesmal +aber wirklich ein krummes Ding. Im Grunde genommen kommt es hier zum +Überschreiben einer Headerdatei und <I>sie</I> (denkt dir +selbst, wer das sein könnte) wollen sich die Option freihalten +zum vorigen Header - mit dem selben Namen - zurückfallen lassen +zu können. Deswegen müssen die Pfade <SPAN STYLE="background: transparent">hart +kodiert</SPAN> werden. Um sich das an vielen Plätzen zu +ersparen, benutzen <I>sie</I> einen #define mit Macro Expansion. Wenn +deshalb deine gcc prefix ein Element enthält, was auch ein Macro +ist - kommt es knüppelhart:</P> +<P>stlport config header: +</P> +<PRE>#define _STLP_NATIVE_INCLUDE_PATH \ + /home/michael/ximian-desktop/ooo/BUILD/ooo/include/c++/3.2.2</PRE><P> +stlport nützliche Macros:</P> +<PRE># define _STLP_MAKE_HEADER(path, header) <path/header> +# define _STLP_NATIVE_CPP_C_HEADER(header) \ + _STLP_MAKE_HEADER(_STLP_NATIVE_INCLUDE_PATH,header)</PRE><P> +und schließlich stlport`s schlaue Einbeziehung (=include +directive): +</P> +<PRE STYLE="margin-bottom: 0.2in">#include _STLP_NATIVE_CPP_C_HEADER(foo)</PRE><P> +Resultat: +</P> +<PRE> g++ ... -D<B>BUILD</B>=<B>7663</B> ... + ... +from /home/michael/ximian-desktop/ooo/<B>BUILD</B>/ooo/OOO_1_0_2/xml2cmp/source/xcd/main.cxx:62: +/home/michael/ximian-desktop/ooo/<B>BUILD</B>/ooo/OOO_1_0_2/solver/641/unxlngi4.pro/inc/stl/cstddef:35:46: +/home/michael/ximian-desktop/ooo/<B>7663</B>/ooo/include/c++/3.2.2/cstddef: No such file or directory + </PRE><H3> +<A NAME="section-10.10"></A>10.10 Für was ist <SPAN STYLE="background: transparent">die +<SPAN STYLE="background: transparent">UNO-Komponentendoku in XML da</SPAN></SPAN>?</H3> +<P><SPAN STYLE="background: transparent">Nicht viel. Obwohl es +durchaus von Wert ist, diese mal runterzuladen, wird ihr zur Zeit +jedoch sogut wie überhaupt keine Beachtung geschenkt.</SPAN></P> +<H3><BR><BR> +</H3> +<H2><A NAME="section11"></A><A NAME="section-11"></A>11. Mit uns +arbeiten</H2> +<P>Siehe das <A HREF="http://ooo.ximian.com/ooo-build.html">About +ooo-build</A> Dokument an (englisch). +</P> +<P><BR><BR> +</P> +<P ALIGN=LEFT STYLE="border-top: none; border-bottom: 1.10pt double #808080; border-left: none; border-right: none; padding-top: 0in; padding-bottom: 0.02in; padding-left: 0in; padding-right: 0in"> +<FONT SIZE=2 STYLE="font-size: 9pt">auf deutsch übersetzt von +Christian Junker °v0.8°</FONT></P> +</BODY> +</HTML> diff --git a/developers/hackers-guide-ja.html b/developers/hackers-guide-ja.html new file mode 100644 index 0000000..9c21512 --- /dev/null +++ b/developers/hackers-guide-ja.html @@ -0,0 +1,1658 @@ +<!doctype html PUBLIC "-//W3C//DTD HTML 4.0//EN"> + +<html lang="ja"> + <head> + <meta lang="ja" http-equiv="content-type" content="text/html; charset=utf-8"> + <title>Unofficial OpenOffice Hacker's guide</title> + </head> + + <body> + <table> + <tr> + <td><a href="hackers-guide.html">English</a></td> + <td><b>Japanese</b></td> + <td><a href="hackers-guide-de.html">German</a></td> + </tr> + </table> + <h1>非公認 OpenOffice ハッカーズガイド</h1> + + <p> + OpenOffice.org (OO.o)をビルドしたり、ハックしたりするには + 本当に長ーーい坂道を登ることが必要とされる。できることならこの + 文章が学習曲線を多少立ち上げの角度を上げて、またより急激に + させて、あなたの助けとなる歩く杖でありたい。《訳注：この部分特に訂正を乞う》 + </p> + + <p> + この文章は時間を節約するために、あなたが現在使われてる妥当なバージョンのLinuxを使っていることを仮定している。真のハッカーは、<a + href="http://www.gnu.org">Free software</a>を使います、また非フリーな要素について読んでいる時間はありません。 + </p> + + <p> + 我々の狙いは、少なくとも以下の質問に答えることです。 + </p> + + <ul> + <li>どうやってOO.oをビルドするのか?</li> + <li>どうやって、開発の輪に入っていけば良いのか?</li> + <li>どうやって、デバッグすれば良いのか?</li> + <li>どうやって、パッチを送れば良いのか?</li> + </ul> + + <h2 id="section-0">0. 目次</h2> + + <ul> + <li><a href="#section-1">1. OO.oを入手する</a></li> + <li><a href="#section-2">2. OO.oをビルドする</a></li> + <li><a href="#section-3">3. OO.oをイントールする</a></li> + <li><a href="#section-4">4. OO.oを実行する</a></li> + <li><a href="#section-5">5. OO.oをハックする</a></li> + <li><a href="#section-6">6. OO.oをデバッグする</a></li> + <li><a href="#section-7">7. パッチを配布するには</a></li> + <li><a href="#section-8">8. その他、TIPS</a></li> + <li><a href="#section-9">9. 有用なリンク集</a></li> + <li><a href="#section-10">10. IFAQ</a></li> + <li><a href="#section-12">11. 我々と一緒にやるには</a></li> + </ul> + <p> + この(一連の)作業の詳細については + <a href="detailed-build-guide.html">詳細ビルド・ガイド</a>で話し合いましょう。. + 我々は、本当に一生懸命に働いて、単なる死すべき運命のプログラマーのための実行可能なプロセスを作りあげました。そして、その簡単な説明を以下に行います。 + </p> + + <h2 id="section-1">1. OO.oを入手する</h2> + + <p> + 複数の優れたパッチセットが存在する、たくさんの競合する + バージョンといくつかの選ばれたブランチのOO.oがあります。 + 私は、CVSスナップショットからのビルドを勧めます。それらは + ビルドできることが知られ、パッチセットが適用できることが知られて + います。さあ、ソースをこのように取得してみましょう： + </p> + <pre> + export CVSROOT=':pserver:anonymous@anoncvs.gnome.org:/cvs/gnome' + cvs login + cvs -z3 checkout -dP openoffice + </pre> + <p> + これらは、OO.oのビルドを行う一式のコピーをあなたの(コンピュータのハードディスクへ)落し込みます。もし、CVSがあなたを驚かせたのなら、最近のパッケージ化されたバージョンも<a href="packages">ここ</a>から取得できます。 + </p> + + <p> + <strong>注記:</strong> あなたは、OO.oをビルドするのに、余分なスペー + スとして4Gバイト以上の領域が必要だ。そして、ビルドするためのソース + コードをダウンロードするのに200Mバイト以上の領域が必要だ。 + </p> + + <h2 id="section-2">2. OO.oをビルドする</h2> + + <h3 id="section-2.1">2.1. configure</h3> + + <p> + ビルドの作業は、かなり複雑である。あなたは今コマンド(《訳注》コマンドライ + ン?)を選択するのだが、とはいえ(ビルドが複雑であることと、コマンドラインを + 選択することが)は、本当の致命傷にはならない。 + </p> + <pre> + ./autogen.sh # the CVS version + ./configure # the packaged version + </pre> + <p> + これは、あなたがビルドしたいのは、スナップショット・ブランチである + という推測である。もし、あなたが別のアイディアとしては、 + --with-tagオプション(例:<pre>--with-tag=OOO_1_0_3</pre>)をこれまで + のブランチと同じように使うことでしょう。 + </p> + + <h3 id="section-2.2">2.2 ダウンロード</h3> + + <p> + あなたが自分のシステムをOO.oをビルドできるように全てのパッケージ + (mozillaや、最近のlibartなどなど)をアップグレードするまでには、あ + なたは(OO.oの)ソースをダウンロードすることができる所に、ほぼ来てい + る。それを行うには、configureを成功させた後に、単に + <pre>./download</pre>と入力して、待てば良い。 + </p> + + <h3 id="section-2.3">make</h3> + + <p> + ここは、ちょっと面倒です。- <pre>make</pre>と入力して、忘れずに + Enterキーを押しましょう。完全なるログ出力が欲しいときには、 + <pre>make 2>&1 | tee /tmp/log</pre>とやってみてはどう? + </p> + + <h2 id="section-3">3. OO.oをインストールする</h2> + + <p> + 完璧にビルドした結果、 + <pre>build/$TAG/instsetoo/unxlngi4.pro/01/normal/</pre>などの場所 + でインストール用セットが完璧にzipで固められた《訳注:そうなの?》 + 状態になっています。あなたは、手動でセットアッププログラムを動かし + てインストールすることができます。<b>または</b><pre>sudo make + install</pre> を実行して あなたのためにシステムプレフィックス設定 + された状態で、OO.oがインストールされます。 + <p> + + <p> + インストールされたら、単にOO.oを再実行することで、サブディレクトリ + のソースを再コンパイルした結果、イントールされたイメージから直接ビ + ルドツリーからリンクすることによりハックしているような気分を得るこ + とができる。これにより、ビルドとテストのサイクルがほんの数十秒で可 + 能になります。それを行うには、例:<pre>linkoo + /usr/lib/ooo-1.0.3 /opt/openoffice/build/RC3_030729</pre> + である + </p> + + <h2 id="section-4">4. OO.oを実行する</h2> + + <p> + linkooを実行するときにプレフィックスを付けたことに、不思議に思った + と思う；そして<pre>cd program; . ./ooenv</pre>を実行したことも。この + 手順がシェルがOO.oを直接実行するための環境設定(セットアップ)になり + ます。その後、<pre>soffice.bin</pre>を実行します。これは、soffice + を実行したり、ラッパスクリプト経由で実行するよりも、<pre>gdb + soffice.bin</pre>のようにデバッガをアタッチするのが大変容易で、良 + い方法です。 + </p> + <p> + <strong>注:</strong> <pre>./soffice.bin</pre>は不可解な理由で完璧に + 動作に失敗するは使わないでください。 + </p> + <p> + <strong>注:</strong> あなたは、oooのラッパを噛ませたOO.oを走らせる + 前に、~/.sversionrcのようなものをを最初に正しく設定するか、または + soffice.binを走らせて、GUI設定ツールを起動させます。これは、あなた + が始める前に一度だけ<pre>oowriter</pre>を実行しておくのです。 + </p> + + <h2 id="section-5">5. OO.oをハックする</h2> + + <h3 id="section-5.0">5.0. 最初のハック</h3> + + <p> + では - われわれは、OO.oをビルドして実行しました。そして、わたし + たちは、あなたのマシンの上でOO.oをハックすることが実際に可能である + 、とわたしたち自身が証明することを望んでいます。では、新しいターミ + ナルの中で、以下のコマンドを実行してみてください: + </p> + <pre> + cd build/$TAG + . ./LinuxIntelEnv.Set.sh + cd vcl + </pre> + <p> + いま、vcl/source/window/toolbox.cxxの中をハックしています; + 私は、例えば、ToolBox::PaintのImplDrawItemの前に<pre>if + (i%2)</pre>を追加してみて、保存します。 + </p> + <p> + まだ vcl/の中にいますか? はい。それから、'build debug=true'と入力 + して、文字列がスクロールして、止るのを待ちます。(5秒ぐらい?)。では、 + <pre>soffice -writer</pre>を再実行します。あなたは、効果が出るのか + を注意しておかねばなりません。 + </p> + <p> + <strong>注:</strong>毎日ハックしているあなたは、ソースツリーの中で' + build'を実行したいと思うでしょう。<strong>やってはいけません</strong> + <pre>openoffice/</pre>ディレクトリの一番上のレベルでmakeを実行する + ことは。あなたは、十中八九、自分が行った変更をゴミ箱行きにすること + になり、(あなたを)意気消沈させます。 + これは、再配置するビルドを行う手助けとして <a + href="#section-10.4">ここ</a>を見て、どこか + <pre>build/OOO_1_1_0</pre>の他のコピー範囲外でありつづけるのは納得 + できる。《訳注:ここも意味不明です。》 + </p> + + <h3 id="section-5.1">5.1. すばらしいマニュアルを読む</h3> + + <p> + C++の力を使うことにより、なお一層簡単に(または、暗黙的に)(よけいな + ことをして)自分から災いを招くような能力が得られます。参考<em>Holub, + Rules for C and C++ programming, McGraw-Hill, 95</em>《訳注:amazon + には原著の在庫はなかった。未訳?》 + </p> + + <p> + 闘いに臨む最高の方法は、OpenOfficeコーディング・ガイドライン + <a href="http://tools.openoffice.org/CodingGuidelines.sxw"> + ここ</a>を読むことであり、c'tor / d'torがコンストラクタ/デストラク + タの略であるとたやすく間違えてしまうことである。 + </p> + + <h3 id="section-5.2">5.2. パッチを送る</h3> + + <p> + bugzilla《訳注:問題解決システム》の中にモジュールのパッチが存在す + ることはまれである。以下のように試して、作業してみるのが簡単である + </p> + + <pre> +cvs status <somefile> | head + </pre> + + <p> + これにより'Repository Revision:'の行、パス、そして2つ目の部分がプ + ロジェクト名を表わします。 + </p> + + <h3 id="section-5.3">5.3 インストーラをハックする</h3> + + <p> + インストーライメージは(実行可能な)テンポラリ・セットアップ・イメー + ジ<tt>/tmp/sv001.tmp</tt>を削除するときには、それを停止させておく + 必要がある。そうするには、セットアップ/インストールに- + dontdeletetempオプションを付けて実行する。《訳注:ここも意味不明な + 日本語になっている》 + </p> + + <h3 id="section-5.4">5.4. 別の部分をハックする</h3> + + <p> + インストールが動作すると、ハックを追加する最も良い方法は、 + <tt>program/lib<em>foo</em>641li.so</tt>にシンボリックリンクをあな + たがビルドしたバージョンに張ることです — ありそうなのは、 + <tt><em>foo</em>/unxlngi4.pro/lib/</tt>ですが。その後、(オフィス) + スイートを実行すると、あなたの行った変更が入っているはずです。 + </p> + + <p> + 例として、あなたが'sal'(System Abstraction Layerの略)をハックした + いとすると、あなたは、/opt/OOInstallからOOO_STABLE_1をインストール + したとすると、あなたはこのようにする必要がある。 + </p> + + <pre> +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 . + </pre> + + <h3 id="section-5.5">5.5. D' make (man)を理解する</h3> + + <p> + システムをビルドしている間、似たような他のシステムがあります。これ + は、また多分ちょっとだけ異なります。概略は、それぞれモジュールを + <i>ビルドしていたもの</i>であり、それから結果が<i>派生</i>した + <a href="http://www.openoffice.org/dev_docs/source/solver.html"> + solver</a>である。おのおののモジュールは、solverの中のヘッダーに対 + してビルドされる。なので、このような少し複雑なことになっている。 + <ul> + <li> + <i>ビルド</i> — このperlスクリプト + <i>solenv/bin/build.pl</i>は、最初にビルドする必要がある全ての + モジュールを確実に<a href="#section-5.5.2">prj/build.lst</a>が + 関連して使用されるようにする。ビルド後のun-windsな内部モジュー + ルの依存関係、また、それぞれのモジュールがディレクトリの変更、 + dmake の組のビルド《訳注:ここも意味不明》 + </li> + <li> + <i>deliver</i> — この perl スクリプト + (<i>solenv/bin/deliver.pl</i>)は、ヘッダやライブラリなどなど<a + href="#section-5.5.3">prj/d.lst</a>形式でsolverを使ってをイン + ストールします。決定的なことは、deliverが、モジュールディレク + トリの中にある solver と同じ場所にインストールされたいかなるファ + イルの日付タイムスタンプを保証することです。この、(特にヘッダー + は)他のモジュールの再ビルドの引き金を引く流れに依存関係がない + ことを保証する。 + <i>deliver</i> — this perl script <i>solenv/bin/deliver.pl</i> + installs headers, and libraries (etc.) into the solver, as + informed by <a href="#section-5.5.3">prj/d.lst</a>. 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. + </li> + </ul> + </p> + + <h4 id="section-5.5.1">5.5.1 標準的なディレクトリ</h3> + + <p> + これらは、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: + + <ul> + <li><b>prj</b> + <ul> + <li> + + <i>build.lst</i> — このディレクトリリストは、'^#'の + コメントを許し、このリストの並び順は、重要ではない。<a + href="#section-5.5.2">詳細</a>を見よ。これは<i>ビルド</i> + 作業が作成する。 + + <i>build.lst</i> — this lists directories to be made, + '^#' comments are allowed, the order of the list is + immaterial see <a href="#section-5.5.2">detail</a>, it + is dictates <i>build</i>'s operation. + </li> + <li> + <i>d.lst</i> — これは<i>deliver</i>プロセスを記述す + る。<a href="#section-5.5.3">詳細</a>を見よ + + <i>d.lst</i> — this file describes the <i>deliver</i> + process, see <a href="#section-5.5.3">detail</a>. + </li> + </ul> + </li> + <li> + <b>util</b> — 一般的なutilディレクトリは、GUIリソース・ + ファイルなどを作成したり、システム・ライブラリに依存関係を追加し + たり、それぞれのサブ・モジュールをサブ・ライブラリをまとめて、一 + つの大きなライブラリにまとめる役目を負っている。 + 全ての作業は、<i>makefile.mk</i>に記述されている。これは、たい + てい、このプロジェクト《訳注:ビルド作業のプロジェクト》が作成 + する最後のディレクトリである。 + + <b>util</b> — 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 + <i>makefile.mk</i>, this is usually the last directory to be + built in a project. + </li> + <li> + <b>inc</b> — 公開ヘッダは通常、'inc' ディレクトリに分離 + される。これらは、'deliver'フェーズに(<i>prj/d.lst</i>を使って) + solverへインストールされます。 + + <b>inc</b> — public headers are typically separated + into an 'inc' directory, these will be installed into + the solver by the 'deliver' phase (using <i>prj/d.lst</i>) + </li> + </ul> + </p> + + <p> + これからもまた、興味深い(深くない)ファイルです: + + There are also various file types that are (or are not) + interesting: + <ul> + <li> + <b>makefile.rc</b> — これからはすべて、冗長であり、無視 + しても大丈夫です。 + + <b>makefile.rc</b> — these are ~all redundant, and can + safely be ignored. + </li> + <li> + <b>makefile.mk</b> — これらは、ソースディレクトリ毎に使 + われる'dmake'ファイルとの(対照によって示される)差異である。 + + <b>makefile.mk</b> — these in contrast are the 'dmake' + files, that are used to build each source directory. + </li> + </ul> + </p> + + <h4 id="section-5.5.2">5.5.2 build.lst</h4> + + <p> + ちょっと見には、build.lst は、おっかないように見える: + On first view build.lst looks scary: + <pre> +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 + </pre> + そう。我々は、実際はパッと見ほど奇妙でない、ここで何が行なわれているのか + をやってみて、解明する必要がある。リストの最初は '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.<p> + + <ul> + <li> + 最初の有効行は、':'を含んでいます。これは、このプロジェクト + (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. + </li> + <li> + その後の、'usr1'という冗長行 [ 楽しみのため? ]が、実際には、 + 魔法の文字列である'nmake'を含んでいる後の部分が正しいのです。 + + Then we have a redundant line 'usr1' [ for fun ? ], in fact + only lines containing the magic string 'nmake' are valid after + this. + </li> + <li> + その次の行は、内部のプロジェクト・ディレクトリ記述します。こ + んな風に: + + The next lines describe internal project directory dependencies + and look like: + <pre> +[shortcut] [path to dir to build] nmake - [flags] [unique-name] [deps...] NULL +vc vcl\source\glyphs nmake - all vc_glyphs vc_unot NULL + </pre> + <i>ショートカット(shortcut)</i> 使いません; <i>フラグ + (flags)</i> どのプラットホームでビルドするかを決定します;通常 + は single char《訳注:wide char(日本などの多バイトを表わす)の + 反対の意味?》のプラットホーム・コードです:'dnpum' 'u'は、Unix + です。より良いシステムは、より多くのいろんなものを生成する' + all'フラグになります。<p> + <i>unique-name</i> これは、マジック名で内部の依存関係を記述す + る別の行で使われます。<i>deps...</i> このファイルがある、いか + なる名前のディレクトリであっても、これは最初にビルドされねば + なりません。 + + <i>shortcut</i> is not used; <i>flags</i> 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'.<p> + <i>unique-name</i> this is a magic name, used by other lines to + describe an internal dependency. <i>deps...</i> any number of names of + other directories in this file, that must be built before this one. + </li> + </ul> + そう、わたしたちは、<i>vcl\source\unotypes</i> (vc_unot) が + <i>vcl\source\glyphs</i> (vc_glyphs)よりも前にビルドされることを知っ + ています。リストの並び順は重要でないのと、単純な順序リストの代わり + に、わたしたちはより複雑な内部用依存関係(保持)システムを持っている + ということを理解することが<b>重要</b>です — この比較により多 + くの他のmakeシステムとの対比になります。 + + So we see in the vcl case that <i>vcl\source\unotypes</i> (vc_unot) has + to be built before <i>vcl\source\glyphs</i> (vc_glyphs). It is + <b>important</b> 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. + <p> + <a href="http://tools.openoffice.org/tools/build.html">ここ</a>に + も、またドキュメントがあります。 + + + There is also documentation <a href="http://tools.openoffice.org/tools/build.html"> + here</a> on it. + <p> + + <h4 id="section-5.5.3">5.5.3 d.lst</h4> + + <p> + build.lstは、build.lstを<i>inc/<module>/build.lst</i>へコ + ピーするような、いくつかのデフォルトのアクションを省略しており、 + d.lstの文法は、build.lstよりも解りやすいです。<p> + <p> + The syntax of d.lst is more comprehensible than build.lst, it omits + some default actions, such as copying build.lst into + <i>inc/<module>/build.lst</i>.<p> + 行の形式: + A line is of the form: + <pre> +[action]: [arguments] +mkdir: %_DEST%\inc%_EXT%\external + </pre> + <pre> +[action]: [arguments] +mkdir: %_DEST%\inc%_EXT%\external + </pre> + どこかでもし、'[action]:'を省略したら、その動作のデフォルトは 'コ + ピー' 動作です。 + 代表的な動作は <i>copy</i>, <i>mkdir</i>, <i>touch</i>, + <i>hedabu</i>,<i>dos</i> and <i>linklib</i>.<p>です。, + where if '[action]:' is omitted, it defaults to the 'copy' action. + Typical actions are <i>copy</i>, <i>mkdir</i>, <i>touch</i>, <i>hedabu</i>, + <i>dos</i> and <i>linklib</i>.<p> + + where if '[action]:' is omitted, it defaults to the 'copy' action. + Typical actions are <i>copy</i>, <i>mkdir</i>, <i>touch</i>, <i>hedabu</i>, + <i>dos</i> and <i>linklib</i>.<p> + + 'hedabu'動作は特に興味深い, inasmuch は、見掛け上インストール時に + ヘッダーを見掛け上再整形して小さくする(または、コピー動作のように + ふるまう) + <p> + 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). + <p> + + 動作中は, 様々なマクロ変数がこのように展開される: + <ul> + <li>%__SRC% — 配布ディレクトリ名 例えば、<i>unxlngi4.pro</i></li> + <li> %_DEST% — solverへの絶対パス 例えば、<i>/opt/OpenOffice/OOO_STABLE_1/solver/641/unxlngi4.pro</i> + </li> + <li> + %_EXT% — (通常はない) way of having マイナー更新 例えば、 + 641.1です。通常サブディレクトリのバージョン名として使われます。 + </li> + </ul> + 一般的なその他は、もし実際にあなたがルールを追加する必要があるとす + る(参考：暗黙のディレクトリコピー)と、それは下記のような形式になる + だろう。 + <pre> +..\%__SRC%\inc\sal\*.h %_DEST%\inc%_EXT%\sal\*.h + </pre> + 注意せよ. 相対パスは、'proj/'ディレクトリへの相対(パス)です + </p> + + + During the action, various macro variables are expanded some of which are: + <ul> + <li>%__SRC% — distribution directory name eg. <i>unxlngi4.pro</i></li> + <li> + %_DEST% — absolute path into solver eg. + <i>/opt/OpenOffice/OOO_STABLE_1/solver/641/unxlngi4.pro</i> + </li> + <li> + %_EXT% — (unusual) way of having minor updates eg. 641.1, + typically used to version every base sub-directory. + </li> + </ul> + Typically then, if indeed you need to add a rule (cf. implicit + directory copies), it will be of the form: + <pre> +..\%__SRC%\inc\sal\*.h %_DEST%\inc%_EXT%\sal\*.h + </pre> + NB. relative paths are relative to the 'prj/' directory. + </p> + + <h3 id="section-5.6">5.6 ファースト イテレーション(繰り返し)</h3> + <h3 id="section-5.6">5.6 fast iteration</h3> + + <p> + これらは、開発サイクルくりかえす、多数の方法です。最上の方法は、 + <a href="section-3">linkoo</a>をつかって、 + インストールセットから あなたのビルドツリーへライブラリをシンボリッ + クリンクを張ることです。そのあと、あなたは単にサブディレクトリを再 + ビルドすることができます。例えば、<pre>vcl</pre>は、 + <pre>build</pre>により実行され、soffice.binを再び実行します。 + </p> + <p> + There are lots of ways to go round a devel iteration; the best + way is to use <a href="section-3">linkoo</a> to symlink the + libraries from the install set directly into your build tree. + Then you can simply re-build a sub-directory eg. <pre>vcl</pre> + by running <pre>build</pre> and re-run soffice.bin. + </p> + + <h3 id="section-5.7">5.7 どうしたら、<code>char *</code>が使えますで + しょうか?</h3> + <h3 id="section-5.7">5.7 Can I get a <code>char *</code>, please?</h3> + + <p> + やっと、かろうじて。 OO.o は少なくとも4つの文字列ラッパーがありま + す。 + </p> + <p> + Just barely. OO.o has at least four string wrappers: + </p> + + <ul> + <li> + <p> + <code>rtl_String</code> — sal/inc/rtl/string.h<br> + "通常は" 文字列およびレファレンスカウンター. + <code>rtlstring->buffer</code> は有用です。そのままで + <code>rtlstring->length</code>. この文字列は、すでに、特定の + キャラクター集合に変換されています; 参照 sal/inc/rtl/textenc.h + — 興味深いケースは、 + <code>RTL_TEXTENCODING_UTF8</code> と、ことによると + <code>RTL_TEXTENCODING_ASCII_US</code> + は、真のラッダイト運動家のためである。 + <code>rtlstring->buffer</code>は、あなたの最愛の<code>char *</code> + <code>rtlstring->buffer</code> と同じように自由に扱えると感じ + るでしょう。 + </p> + <p> + <code>rtl_String</code> — sal/inc/rtl/string.h<br> + "Normal" string plus reference counting. + <code>rtlstring->buffer</code> is useful, as is + <code>rtlstring->length</code>. This string has already + been converted to a particular character set; see + sal/inc/rtl/textenc.h — the only interesting cases are + <code>RTL_TEXTENCODING_UTF8</code> and perhaps + <code>RTL_TEXTENCODING_ASCII_US</code> + for real luddites. Feel free to treat + <code>rtlstring->buffer</code> as your beloved <code>char *</code>. + </p> + </li> + + <li> + <p> + <code>OString</code> — sal/inc/rtl/string.hxx<br> + は、単に rtl_String を <code>class</code>に ラッピングしていま + す。あなたは、<code>ostring.pData</code>をrtl_String(パブリッ + ク属性だ)を取得するに使うことができる。<code>OString</code> は、 + もしあなたが必要とするなら、妥当で使いやすいメソッドです。 + </p> + <p> + <code>OString</code> — sal/inc/rtl/string.hxx<br> + Simply a rtl_String wrapped inside a <code>class</code>; you + can use <code>ostring.pData</code> to get at the rtl_String + (it's public). <code>OString</code> has reasonably useful + methods for if you need them. + </p> + </li> + + <li> + <p> + <code>rtl_uString</code> — sal/inc/rtl/ustring.h<br> + "通常は" ユニコード文字列, rtl_Stringと同様で、参照カウンタも + 同様である。しかしながら、この型は、常にUCS-2エンコードである。 + 思うにJavaの疑わしき選択への互換性のためのエンコードである + </p> + <p> + <code>rtl_uString</code> — sal/inc/rtl/ustring.h<br> + "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. + </p> + </li> + + <li> + <p> + <code>OUString</code> — sal/inc/rtl/ustring.hxx<br> + rtl_uStringは、<code>class</code>の中にラップされている. + これは、OO.oのコードの大部分がこの文字列をこの型に入れている。 + </p> + <p> + <code>OUString</code> — sal/inc/rtl/ustring.hxx<br> + An rtl_uString wrapped inside a <code>class</code>. This is + what most of the OO.o code uses to pass strings around. + </p> + </li> + </ul> + + <p> + 真の男は、UTF-8エンコード文字列を<code>char *</code>で扱う。 + 'printf'のような、<code>OUString</code>からchar *を導き出すことが + 必要ないかなるシステムAPIは、下記のように使用する: + </p> + <p> + Since real men use <code>char *</code> strings encoded in UTF-8; + to use any system API such as 'printf' you need to extract a + char * from a <code>OUString</code> use this: + </p> + + <pre> +static char * +gimme_utf8_please (const rtl::OUString &oustring) +{ + rtl::OString ostring; + + ostring = ::rtl::OUStringToOString (oustring, RTL_TEXTENCODING_UTF8); + return strdup (ostring.pData->buffer); +} + </pre> + + <p> + 逆の場合: + </p> + <p> + And the reverse: + </p> + + <pre> +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); +} + </pre> + + <h4 id="section-5.7.1">5.7.1. 落とし穴</h4> + <h4 id="section-5.7.1">5.7.1. Pitfalls</h4> + + <p> + <strong>重要</strong> rtl_String や rtl_uString + APIは、かなり不細工だ. 新しい文字列を作成するこれらの機能は、あな + たが、下記のように、これら(rtl_Stringやrtl_uString)を呼出す前に文字 + 列にNULLを入れて、元の値を設定しなくては*ならない*; + </p> + <p> + <strong>Important</strong> The rtl_String and rtl_uString + APIs are massively clunky. For the functions that create new + strings, you <em>have</em> to set the original value of the + string to NULL before calling them, like this: + </p> + + <pre> +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"); + </pre> + + <p> + これらの関数が、もしそれらがNULLでなければ文字列をrelease()する関 + 数の変種を最初に呼出す試みする。というのが理由である。— + メモリリークを避ける原則として、あなたは文字列を再設定した方が良い。 + ;実際あなたの人生を難しくしている(単におおげさにいっているだけで、 + ややこしくしているぐらいで良いか) + </p> + <p> + 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. + </p> + + <h4 id="section-5.7.2">5.7.2. GDBから文字列を調べる</h4> + <h4 id="section-5.7.2">5.7.2. Examining strings from GDB</h4> + + <p> + 我々は既にOO.oが粗末な<code>char *</code>を使っていないことを見て + きた。もしあなたがコードを書くことは十分だと考えているなら、あなた + は、OO.oをデバッグしなければならなくなるまで待たなくてはならない。 + 文字列をどのように取りだすかがこの節です: + </p> + <p> + We have already seen that OO.o does not use humble <code>char *</code> + 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: + </p> + + <ul> + <li>rtl_String: その中を見よ</li> + <li>rtl_String: just poke at it</li> + <li>文字列: — 注, decl'は'UniString'マクロを使って、 + tools/inc/string.hxxの読み手を混乱させます。 + <i>FIXME: UniStringsのマクロをきちんと出力する</i> + あなたがたぶん望むように出力できるような形式に機械的に変換する: + <pre> +fprintf (stderr, "String is '%s'\n", + (::rtl::OString (<i>MyString</i>.GetBuffer (), + <i>MyString</i>.Len(), + RTL_TEXTENCODING_UTF8)).getStr()); + </pre> + もちろん、stdio.hとrtl/string.hxxが欠けているならインクルードする + 必要があります。 + </li> + <li>String: — note, the decl' of this uses the macro + 'UniString' to confuse readers of tools/inc/string.hxx, + <i>FIXME: need a macro to dump UniStrings nicely</i> + To convert programmatically to something you can print + you probably want: + <pre> +fprintf (stderr, "String is '%s'\n", + (::rtl::OString (<i>MyString</i>.GetBuffer (), + <i>MyString</i>.Len(), + RTL_TEXTENCODING_UTF8)).getStr()); + </pre> + of course, you also need to include stdio.h and rtl/string.hxx if +they are missing. + </li> + <li>OString: <i>gdbのコマンドプロンプトでp str->pDataと入れよ</i></li> + <li>OString: <i>p str->pData</i></li> + <li>OUString, rtl_uString: あなたの~/.gdbinitに下記の記述が必要で + す: + <pre> +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 + </pre> + 注. 理解できない理由によりgdbは、2回目に単一の文字列を表示します + 'rtl_uString *'のために<i>prtls</i> と'OUString *'のために pouを使 + います。OUStringはあなたが望むように機械的に出力します: + <pre> +::rtl::OString tmpStr = OUStringToOString (<i>MyOUString</i>, RTL_TEXTENCODING_UTF8); +fprintf (stderr, "String is '%s'\n", tmpStr.getStr()); + </pre> + </li> + <li>OUString, rtl_uString: you're going to need this in your + ~/.gdbinit: + <pre> +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 + </pre> + NB. for reasons unknown gdb will take ~seconds to print a single string. + Use <i>prtls</i> for 'rtl_uString *' and pou for 'OUString *'. To + programatically print a OUString you need: + <pre> +::rtl::OString tmpStr = OUStringToOString (<i>MyOUString</i>, RTL_TEXTENCODING_UTF8); +fprintf (stderr, "String is '%s'\n", tmpStr.getStr()); + </pre> + </li> + </ul> + + <h2 id="section-6">6. OO.oをデバッグする</h2> + <h2 id="section-6">6. Debugging OO.o</h2> + + <p> + この節では、gdbはコンソールから使っていると仮定している。 + </p> + <p> + This section assumes use of gdb, from the console. + </p> + + <h3 id="section-6.1">6.1. デバッグシンボルを付けてビルドを行う</h3> + <h3 id="section-6.1">6.1. Building with debugging symbols</h3> + + <p> + <tt>build debug=true</tt> コマンドをモジュール毎に行うことによって、 + OO.oは、デバッグコードをモジュール毎に加える方法を含んでいる。 + 残念なことだが、この(方法)は、それに たっぷりのアサーション、大量 + に発生しているワーニング、さまざまなその他のチェックが致命的なデバッ + グシンボルを含んでおり、プロジェクト全体を実行するには勧められない。 + </p> + <p> + OO.o includes a way to add debugging code in per module, via + the <tt>build debug=true</tt> 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. + </p> + <p> + このように、すべてにデバッグシンボルを付けることを望むなら、 + 幾つかのmakefileにデバッグシンボルを追加するように変更し、下記のパッ + チを適用します。[注.この作成したOOバイナリは~1ギガバイトより小さい。 + フルビルドツリーなら~8ギガバイトである] + </p> + <p> + 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: + </p> + <pre> +--- 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)"=="" + </pre> + <p> + もちろん、デバッグシンボルなしでは、gdbは使いずらい。ベースディレ + クトリにある上記のパッチを、/tmp/fooにカットアンドペーストしてパッ + チを適用する。 + </p> + <p> + 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: + </p> + <pre> +patch -p0 < /tmp/foo + </pre> + + <h3 id="section-6.2">6.2. ブレークポイントを設定する</h3> + <h3 id="section-6.2">6.2. Setting breakpoints</h3> + + <p> + gdbで壊れ具合によって、もっともありそうなのが、動きそうにない(バイ + ナリを)実行する前にブレークポイントを設定することです。 + このようなスキームが最善です。 + </p> + <p> + 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: + </p> + + <pre> +gdb ./soffice +break main +run # don't forget the arguments here +# ... traps in main ... +break osl_readFile +continue + </pre> + + <p> + もちろん、もし、コードが、巨大なOO.oのコードの大部分accountsは + dlopenedした後のライブラリに実装されて、それが動くとは思っていな + い。 + このように、あなたは、コードがロードされて、ブレークポイントが設定 + された場所で止まるのを捉える必要がある。osl_psz_loadModuleの中でパ + シッとブレークポイント止めて、やってみよう。 + </p> + <p> + 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. + </p> + + <p> + 別の方法として、コードに実行させるとするなら、(ソースコードに) + #include <signal.h>を追加するのが簡単です。; そして、 + raise (SIGSTOP)を(止めたい場所に)置きます。; (ソース)コードのどこ + かデバッガ中でtrap out(停止用割こみを発生させる?)する。 + </p> + <p> + 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. + </p> + + <h3 id="section-6.3">6.3. 開始の始まり</h3> + <h3 id="section-6.3">6.3. Starting at the beginning</h3> + + <p> + われわれは、vcl/source/app/svmain.cxx (SVMain)が呼んでいるsalラッ + パーのmain関数の最初にいます。それは、mainのpSVData->mpAppから呼び + だされます。しかし、pSVDataはローカルのインライン(変数?)です。 + デバッグをするために、グローバル変数であるpImplSVDataを使います。 + 例えば + <pre> + p pImplSVData->maAppData + </pre> + これが典型的な 'main'メソッドです: + desktop/source/app/app.cxx (Main). + </p> + <p> + 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: + <pre> + p pImplSVData->maAppData + </pre> + This 'Main' method is typically: + desktop/source/app/app.cxx (Main). + </p> + + <h3 id="section-6.4">6.4. 文字列を調べる</h3> + <h3 id="section-6.4">6.4. Examining strings</h3> + + <p> + 粗末な char *(gdbは、なにもしなくてもchar *を表示することができる) + は、gdbが理解できない無数の異なるクラスで、それ(char *?)は、ラッビッ + ングされているオブジェクト(指向)の世界では避けられている。さらに悪 + いことに、文字列をプリントするのですら極端に難しい場合がほとんどで + す。-- この結果は、ucs-2エンコードで行くというぞっとするような決定 + によります。これは、変りやすい、変りにくい文字クラスの両方に言えま + す。 + </p> + <p> + 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. + </p> + + <p> + <a href="#section-5.7.2">5.7.2節</a>を読んで、OOoの中でどのように + 文字列が動作しているかと、デバッグ用TIPSの知識を得てください。 + </p> + <p> + Please read <a href="#section-5.7.2">section 5.7.2</a> to see + how strings work in OO.o and to get some debugging tips. + </p> + + <h3 id="section-6.5">6.5 正しいビルドの順序を知る</h3> + <h3 id="section-6.5">6.5 Getting the build order right</h3> + + <p> + ビルドのモジュール依存関係は、すっきりとしたビルドを行うために非常 + に重要なことであるのは、明白である。モジュール中で、'build'と入力 + すると、最初ビルドは、prj/build.listを調べます。たとえば、 + neon/prj/build.lst:は + <pre> +xh neon : soltools external expat NULL + </pre> + 'soltools', 'external' や 'expat' という限定詞は、満足にビルドされ、 + neonがビルドできる前に望んだ結果が出なくてはならない。時々これらの + ルールが壊れて、しばらくの間人々に警告されない。 + </p> + <p> + 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: + <pre> +xh neon : soltools external expat NULL + </pre> + 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. + </p> + + <h3 id="section-6.6">6.6 gdbの中だけで落ちるんだけど</h3> + <h3 id="section-6.6">6.6 It crashes, but only in gdb</h3> + + <p> + 面白いことに — あなたが、インストールツリーの中で + desktop/unxlngi4.pro/bin/sofficeをsoffice.binにリンクを張ったとす + ると? 実行するだけなら、十分に動く。しかし、gdbがシンボリックリン + クを展開して、パス中の(実行)バイナリの捜索をできなくし、(gdbに) + argv[0]で与えられるような完全パスを渡します。これ(gdb)には、 + /opt/OpenOffice/OOO_STABLE_1/desktop/unxlngi4.pro/binのようなプロ + グラムのベースパスが割当てられ、そこから探し始められます。(例 + applicat.rdb) もちろん、いかなる設定情報も見つけられない時は、それ + は静かにどこかでクラッシュするか、元の問題から遠く離れた所にいます。 + </p> + <p> + 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. + </p> + + <h3 id="section-6.7">6.7 クラッシュしたり、クラッシュしなかったりし + ます</h3> + <h3 id="section-6.7">6.7 It crashes, but doesn't crash</h3> + + <p> + 様々な理由により、人生が混乱するよりはシグナルハンドラが起動されま + す。それは、このように作られているのが一番です。 +<pre> +--- 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; + +</pre> + 注. 後続のスペース + </p> + <p> + For various reasons signal handlers are trapped and life + can get rather confusing; thus it's best for builders to + apply something like this: +<pre> +--- 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; + +</pre> + NB. trailing space. + </p> + + <h3 id="section-6.8">6.8 トレースした結果からコードを見つけられない</h3> + <h3 id="section-6.8">6.8 I can't find the code from the trace</h3> + + <p> + 幾つかのメソッドは、コールバックとして使うことができる特別なリンケー + ジを持っていると記述されている。それらは、通常'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. + <pre> + IMPL_LINK( Window, ImplHandlePaintHdl, void*, EMPTYARG ) + </pre> + builds the 'LinkStubImplHandlePaintHdl' method. + </p> + <p> + 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. + <pre> + IMPL_LINK( Window, ImplHandlePaintHdl, void*, EMPTYARG ) + </pre> + builds the 'LinkStubImplHandlePaintHdl' method. + </p> + + <h3 id="section-6.9">6.9 トレースで見たファイルだけを再コンパイルするには</h3> + + <p> + デバックオプションをつけないビルドでgdbを使うと、耐えられずに(例えば) + oowriterの全てを再コンパイルしたくなるでしょう。だから、私達はperlのヘルプ + アプリケーションを作りました。そのperlヘルプアプリケーションはスタックのな + かで興味のあるメソッドやクラスの名前をコピペすることによって、それらの文字 + 列を含むファイルだけをtouchすることができ、再コンパイルするのが容易になり + ます。以下は典型的なデバッグの流れです: + </p> + <pre> + 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<com::sun::star::document::XImporter> const*) () from ./libsfx641li.so +... + quit + cd base/OOO_STABLE_1/sfx2 + ootouch SfxMedium + build debug=true + </pre> + <p> + こうして、SfxMediumを参照したりインプリメントしているなにもかもがtouchさ + れ、それによりデバッグシンボル付きで再ビルドします。 + </p> + + <h3 id="section-6.10">6.10 あるソースディレクトリにあるファイルのみを再ビ + ルドするには</h3> + + <p> + もし、カレントディレクトリにあるコードのみを再コンパイルしたいのならば、 + killobj dmakeターゲットを使うことによってそのオブジェクトファイルを削除 + することができます: + </p> + <pre> + dmake killobj + dmake + </pre> + + <h3 id="section-6.11">6.11 いつもsal_XErrorHdlでクラッシュするんだけど...</h3> + + <p> + 非同期なXエラー報告が原因です。 + <pre>export SAL_SYNCHRONIZE=1</pre> + とすることによって、全てのXの通信を同期させ、そのエラーを起こしたメソッ + ドによりエラーを報告するようになるが、OOoの動作をぐんと遅くもさせます。 + </p> + + <h3 id="section-6.12">6.12 ワードファイルを読み込んだら黙って落ちるんだけ + ど...</h3> + + <p> + Caolanの提案するには: ww8par.cxxのSwWW8ImplReader::LoadDocの最初と最後に + ブレイクポイントを置くことによって、できるかぎり重要なフィルタをドキュメ + ントが得ることを確認します。 + </p> + <p> + 熟練者はSwWWI8ImplReader::ReadPlainCharsにブレークポイントを置けば、読 + み込まれたテキストの塊を見ることができます。あるいは、 + SwWWI8ImplReader::AppendTxtNodeは挿入された各段落を見ることができます。 + </p> + + <h2 id="section-7">7. パッチを配布するには</h2> + + <h3 id="section-7.1">7.1. Diffスタイル</h3> + + <p> + 常に'cvs -z3 diff -u'としてunified形式を使ってください。なぜならば、それ + が一番見やすく、しかも読んで適用するのに適切なdiffのタイプだからです。 + </p> + + <h3 id="section-7.2">7.2. うまく取り込んでもらうためには</h3> + + <p> + 手を動かす前に、どうやったらあなたのパッチをうまく取り込んでもらえるのか + ということを考えたり、開発者とそのことについて相談したりするのはよいこと + です。 + そのうちのお薦めの方法は、<a + href="mailto:dev@openoffice.org">dev@openoffice.org</a>に投稿するか + <tt>irc.freenode.net</tt>の<tt>#OpenOffice.org</tt>チャンネルにIRCで潜ん + でいることです。IRCはとても使えないコミュニケーション媒体ですが、コミュ + ニケーションをしないよりはましでしょう。<a href="name-account.html">ここ + </a>を見れば、誰が誰だかがわかります。 + </p> + + <h3 id="section-7.3">7.3. ooo-buildパッチの作り方</h3> + <p> + 私達のパッチインフラについてのより多くを知りたければ<a + href="ooo-build.html#section-2.2">ここ</a>を見てください。 + </p> + + <h2 id="section-8">8. その他、TIPS</h2> + + <h3 id="section-8.1">8.1. CVSアカウントを取得する</h3> + + <p> + Issueが報告される過程がどのようになっているのか見るには例えばissue #7270 + を見てください。アカウントを取得したら、まず以下のようにしてセキュアCVS + サーバにトンネルを作る必要があります。 + </p> + + <pre> +ssh -f -2 -P -L 2401:localhost:2401 tunnel@openoffice.org sleep 1400 < /dev/null > /dev/null + </pre> + + <p> + そしたら、トンネルの終端をローカルマシンにするために、CVSROOTをローカルマ + シンのところに変更しましょう。 + </p> + + <pre> +:pserver:mmeeks@localhost:/cvs + </pre> + + <p> + ログインすると、すぐにあなたのCVSの設定を新しいサーバに移さなければいけ + ないことに気づくでしょう。これをB/Wを無駄にせずにやるには:[遅いけど効果 + 的です] + </p> + + <pre> +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\///' {} \; + </pre> + + <h3 id="section-8.2">8.2 patchやdiffを使う</h3> + + <p> + patchやdiffは素晴らしいツールです。しかし、人々はこれらのツールを混乱させ、 + その解決が困難なデータを渡すことがよくあります。以下は、これらの混乱を解決 + するためのいくつかのヒントです。 + </p> + + <ul> + <li>自信がなかったら、まず--dry-runオプションを付けてpatchコマンドを実行し + ましょう。これはpatchを作っているように見えますが、実際にpatchを作って + いるわけではありません。これは内部依存のパッチの組合せとともにインチキ + な結果を返すことがありますが、しかしそれを補ってあまり余る便利さがあり + ます。 + <li>たいていの場合は"patch -p0"としてください。0はdiffが示すファイルパスの + 先頭からいくつのスラッシュ(とその間にあるディレクトリ名)を取り除くかを表 + します。 + <li>途中でわけ分からなくなって、パッチの半分がすでに適用されてしまって、元 + 戻したいというときには、ファイルを消去してCVSでアップデートするか、-Rオ + プションを付けてパッチをあて直します。 + <li>たまに、diffを空白の変更が沢山あるモジュール間で使うとパッチが読みづら + なります。diffで'-w'フラグを利用すればこの問題を読みやすくなります。 + </ul> + + <h3 id="section-8.3">8.3 make clean</h3> + + <p> + トップレベルディレクトリで<i>dmake clean</i>とするだけです。HEADにはclean + ターゲットがありませんが、dmake cleanがやっていることをやっていることの代 + わりとして、以下のようにします。 + </p> + +<pre> +find -name 'unxlngi4.pro' -exec rm -Rf {} \; +</pre> + + <h3 id="section-8.4">8.4 CVSの設定</h3> + + <p> + バンド幅を効率よく利用するためには、適切なdiffをデフォルトで作るようにしま + しょう。~/.cvsrcに以下の記述を追加しましょう。 + </p> +<pre> +cvs -z3 -q +diff -upN +update -dP +checkout -dP +status -v +</pre> + + <h3 id="section-8.5">8.5. ヘッダファイルを追加する</h3> + + <p> + 分かっているとは思いますが、OOoにヘッダファイルを追加するのは面倒です。 + ヘッダファイルをexternal/に追加するには、ヘッダファイルを + external/prj/d.lstに追加しましょう。ビルドするときに + solver/641/unxlngi4.pro/inc/externalディレクトリにコピーされます。 + </p> + + <h3 id="section-8.6">8.6. Finding where to hack</h3> + + <p> + 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 <a href="http://ooo.ximian.com/lxr">LXR</a>'s + <b>text</b> 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: ... + </p> +<!-- + <h3 id="section-8.X">8.X. Not failing at the first error</h3> + + <p> + If you're leaving the computer for some time, and you know what + you're doing, it can be worthwhile doing a make that skips minor + build errors by using <pre>dmake -i</pre> ( similar to gmake -k ), + however this can result in an apparently successful but broken + build: not suitable for new builders. + </p> +--> + + <h2 id="section-9">9. 有用なリンク集</h2> + + <h3 id="section-9.1">9.1. www.OpenOffice.org</h3> + + <p> + 初期のOpenOffice.orgという組織のほとんどがハッカー志向のものではありませ + んが、ちょっと探せば便利な<a + href="http://www.openoffice.org/documentation.html">ドキュメント</a>が沢 + 山あります。 + </p> + + <p> + OOoのニュースや、他には無い独特のOOoの情報を知りたければ<a + href="http://www.ooodocs.org">ooodocs.org</a>を見てください。 + </p> + + <p> + 他には: + + <a href="http://ooodi.sourceforge.net/">OOODI</a>はGtk+ディクショナリイン + ストーラーを制作しています。 + + <a href="http://ooextras.sourceforge.net">OOExtras</a>はテンプレートやマ + クロ、クリップアートを提供しています。 + + <a href="http://ooqstart.sourceforge.net">Quickstart applet</a>はGnome向 + けですが、<a + href="http://segfaultskde.berlios.de/index.php?content=oooqs">KDE向け + </a>のもあります。 + + <a href="http://dict.progbits.com">Dictionaries & Docs</a>はKevin + Hendricksによる提供です。 + <p> + + <h3 id="section-9.2">9.2. Patch archives</h3> + + <p> + OpenOffice.orgが沢山のリリースをしている一方で、異なるプロジェクト同士が + OOoに対して沢山のパッチ(しかもでかい奴)を投げます。幸いにも、かなりの割 + 合で折り返すことができるので、どのパッチもビルドするためにHEADには必要あ + りません。例えば、多くのものがOOO_STABLE_1に取り入れられました。それにも + かかわらず、これらのいくつかあるいは全てを利用することは必要です。 + </p> + + <ul> + <li> + <a href="http://ooo.ximian.com">Ximian</a>のパッチとビルドツールやスナップ + ショットは全て<a + href="http://ooo.ximian.com/packages">パッケージ</a>または<a + href="http://ooo.ximian.com/patches">パッチ</a>として利用可能です。 + </li> + <li> + <a href="http://www.debian.org">Debian</a>の役に立つOOoの<a + href="http://www.linux-debian.de/openoffice/">ページ</a>にはパッチがありま + す。Debianの<a + href="http://cvs.debian.org/oo-deb/debian/?cvsroot=debian-openoffice"> + CVS</a>も有用です。 + </li> + <li> + <a href="http://www.linux-mandrake.com">Mandrake</a>のOOo<a + href="http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/SPECS/OpenOffice.org/"> + パッチ集</a>。 + </li> + <li> + <a href="http://www.freebsd.org/cgi/cvsweb.cgi/ports/editors/openoffice/#dirlist"> + FreeBSD</a>のOOo portのパッチ。 + </li> + <li> + Red Hat'sの(Mandrakeのに基づいた).specファイルも読む価値があり、Red Hat + の<a + href="http://rawhide.redhat.com/pub/redhat/linux/rawhide/SRPMS/SRPMS/openoffice-1.0.1-6.src.rpm">SRPM</a>にあります。 + </li> + <li> + OOoをローカライズしたい人はPavel Janikによる<a + href="ftp://ftp.linux.cz/pub/linux/people/pavel_janik/OpenOffice.org_1.0.1_CZ/build-13/build/Patches">パッチ</a>を見て勉強しましょう。 + </li> + </ul> + + <h2 id="section-10">10. (めったにない) FAQ</h2> + + <h3 id="section-10.1">10.1. どうして'mws_srx644'などといったブランチは奇数 + 番号をとらないのか？</h3> + + <p> + 週ごとにフリーズしsolverや開発環境がリリースされるため、この値は週ごとに + 増え、発散します。しかし、最近幅広いリリースのための単体のビルドを作るプ + ロセスが困ったことに一週間以上かかるために英数字が混じったリリースタグが + うたれます。mwsはMaster Workspaceを意味します。 + </p> + + <h3 id="section-10.2">10.2. どうして<b>ビルド</b>するのにJavaがいるの?</h3> + + <p> + どうしても、コンポーネントやいろんなサービスを登録するのに沢山のXMLファ + イルが必要になります。Javaを使えばこれらの操作が簡単に行えます。さらに、 + Javaがマシンにインストールされていれば、OOoを実行するときにもうまい具合 + にJavaが使われます。 + </p> + + <h3 id="section-10.3">10.3. なんで[t]cshは使えないの?</h3> + + <p> + これは少しばかり不可解です。コマンドを標準出力にパイプする方法が端末から + 入力するのとで、決定的に違います。 + </p> + + <pre>echo 'echo #define DLL_NAME "libsch641li.so" >./foo.hxx' | /bin/tcsh -s</pre> + + <p> + は、同じものをシェルで打ったらうまくいくのに、失敗します。なんか変ですが、 + </p> + + <pre>tcsh -fc 'echo #define DLL_NAME "libsch641li.so" >./foo.hxx'</pre> + + <p> + ならうまくいきます。<a + href="http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/">csh</a>も参考 + にしてください。 + </p> + + <h3 id="section-10.4">10.4. ビルドの場所を移動させたのだけれど、なんでうま + くいかないの ?</h3> + + <p> + <pre>relocate /path/to/new/build/</pre>を実行させなければいけません。 + 他の面倒な方法として、再設定しなればいけないもの(LinuxIntelEnv.Setも新し + いパスが必要だし、シェルに再インポートしなければいけません。)があり、相 + 対パスで記述されていないので、 + + </p> + <p> + The simple answer is: you need to run <pre>relocate /path/to/new/build</pre>; + another more complex answer is: + </p> + <p> + Well, <b>assuming</b> 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: + <pre> +find -name '*.dpc*' -exec rm {} \; + </pre> + </p> + <p> + The stlport does some really <a href="#section-10.10">broken</a> 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). + </p> + + <h3 id="section-10.5">10.5 CVSが'Fatal Error aborting. [acc] no such user' + というエラーを吐きます。どうして？</h3> + + <p> + あなたのユーザ名が登録されていないことが考えられます。大抵はあなたの~ + /.cvspassが失われて、すでにログアウトされているのが原因です。ログインし + なおして、同じコマンドを打ってみてください。 + </p> + + <h3 id="section-10.6">10.6 'unxlngi4.pro'の'.pro'は何を意味してるの?</h3> + + <p> + <i>Pro</i>ductです。こんなん明らかでしょ。 + </p> + + <h3 id="section-10.7">10.7 OpenOffice.orgってどんな感じでできてるの?</h3> + + <p> + さっきこんな図を見つけてきたので、貼っておきます。 + </p> + <img src="layers.png" alt="Abstraction Layers"> + + <h3 id="section-10.8">10.8 どうやってOOoのスクリーンショットを撮るのですか?</h3> + + <p> + OOoはX resoucesにとても変なことをします。このように古いスクリーンショッ + トをとるアプリケーションは正確なスクリーンショットを撮ることができませ + ん。しかし、ImageMagickのimportコマンドは使えます。 + <pre>import foo.png</pre> + あるいは、 + <pre>sleep 2; import ^window root foo.png</pre> + とコンソールで打ちます。 + + (注)スクリーンを小さく見せたいのでなければ、ツールバーのアイコンをまず + 大きくする必要があります。 + </p> + + <h3 id="section-10.9">10.9 I tried to build with gcc on a prefix with BUILD in it why does it break ?</h3> + <p> + 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 + <b>if your gcc prefix contains an element which is a macro - you're stuffed</b>: + </p> + <p> + stlport config header: <pre>#define _STLP_NATIVE_INCLUDE_PATH \ + /home/michael/ximian-desktop/ooo/BUILD/ooo/include/c++/3.2.2</pre> + stlport helpful macros:<pre># define _STLP_MAKE_HEADER(path, header) <path/header> +# define _STLP_NATIVE_CPP_C_HEADER(header) \ + _STLP_MAKE_HEADER(_STLP_NATIVE_INCLUDE_PATH,header)</pre> and finally + stlport cunning native include: <pre>#include _STLP_NATIVE_CPP_C_HEADER(foo)</pre> + </p> + <p> + Net result: + <pre> + g++ ... -D<b>BUILD</b>=<b>7663</b> ... + ... +from /home/michael/ximian-desktop/ooo/<b>BUILD</b>/ooo/OOO_1_0_2/xml2cmp/source/xcd/main.cxx:62: +/home/michael/ximian-desktop/ooo/<b>BUILD</b>/ooo/OOO_1_0_2/solver/641/unxlngi4.pro/inc/stl/cstddef:35:46: +/home/michael/ximian-desktop/ooo/<b>7663</b>/ooo/include/c++/3.2.2/cstddef: No such file or directory + </pre> + </p> + + <h3 id="section-10.10">10.10 UNOコンポーネントのXML descriptionはなんのた + めにあるの ?</h3> + <p> + 大したものではありません。インストールするときに意味がありますが、しかし + いまのところほとんど使われていません。 + </p> + + <h3 id="section-10.11">10.11 なんでこんなにコードが見づらいのか?</h3> + + <p> + コードを書く人は変なエディタを使わなければいけません。タブストップは4文 + 字になっていると思われます。もちろん、タブ幅が8文字と思われるUnixのエディ + タで編集したファイルは見づらくなります。 + </p> + <p> + もしたまたま + <a href="http://www.gnu.org/software/emacs/">本物のエディタ</a>を使って + いるのであれば、ピンク色の眼鏡を売ります。 + <a + href="http://ooo.ximian.com/emacs.el">http://ooo.ximian.com/emacs.el</a> + を<tt>.emacs</tt>に貼りつけるか、あるいはこのファイルを<tt>(load + "/path/to/that/file.el")</tt>として読みこんでください。 + <tt>my-openoffice-path-regexp</tt>を自分の環境に適合させるのを忘れないで + ください。 + </p> + <p> + これにより、emacsはOOoのソースファイルには4文字幅のタブを使います。 + (さらに、<tt>sdi</tt>、<tt>hrc</tt>、<tt>src</tt>ファイルに対する<em>C++ + モード</em>にも同様に4文字幅のタブを使います。) + </p> + + <h2 id="section-11">11. 私たちと一緒に作業しよう</h2> + <p> + <a href="ooo-build.html">About ooo-build</a>をみてください。 + </p> + + <hr> + <p>If you have more hacking tips, corrections, a grip of correct + spelling etc. please do mail <a href="http://www.gnome.org/~michael">me</a>, + at <a href="mailto:michael.meeks@novell.com">michael.meeks@novell.com</a>.</p> + 《訳注：翻訳に関することは, yabuki [at] netfort.gr.jp へ。必ず応答できるとは限りませんが, 具体的な訂正意見は歓迎します.》 + 《訳注：翻訳は, Yukiharu YABUKI と Takashi Nakamoto が行いました.》 + </body> +</html> diff --git a/developers/hackers-guide.html b/developers/hackers-guide.html new file mode 100644 index 0000000..e8d9eb4 --- /dev/null +++ b/developers/hackers-guide.html @@ -0,0 +1,1202 @@ +<!doctype html PUBLIC "-//W3C//DTD HTML 4.0//EN"> + +<html lang="en"> + <head> + <meta lang="en" http-equiv="content-type" content="text/html; charset=ISO-8859-1"> + <title>Unofficial OpenOffice Hacker's guide for 2.0</title> + </head> + + <body> + <table> + <tr> + <td><b>English</b></td> +<!-- <td><a href="hackers-guide-1.1-ja.html">Japanese</a></td> + <td><a href="hackers-guide-1.1-de.html">German</a></td> --> + </tr> + </table> + + <p><br><b>This guide is becoming obsolete - see the <a + href="http://wiki.services.openoffice.org/wiki/Main_Page">wiki</a> for better maintained + information</b><br><br></p> + + <h1>Unofficial OpenOffice Hacker's guide for 2.0</h1> + + <p> + Building and hacking on OpenOffice.org (OO.o) entails climbing a + fairly lengthy incline. Hopefully this document will make the + learning curve somewhat steeper and more abrupt, and will + give you a walking stick to help you out. <a + href="old-guides.html">Older hackers guides</a> targetting the 1.1 + tree are available (also in German & Japanese). + </p> + + <p> + This document assumes that you'll be using a reasonably current + Linux system, as a time saving feature. Real hackers use <a + href="http://www.gnu.org">Free software</a>, and don't have time + to read about non-Free stuff. + </p> + + <p> + We aim to answer at least the following questions: + </p> + + <ul> + <li>How do I build OO.o</li> + <li>How do I go around a development iteration</li> + <li>How do I debug it</li> + <li>How do I send a patch</li> + </ul> + + <p> + If you need help getting OO.o build, and you intend to hack on + it, please join the mailing list <a + href="http://lists.ximian.com/mailman/listinfo/openoffice"> + here</a> and ask questions there. + </p> + + <h2 id="section-0">0. Contents</h2> + + <ul> + <li><a href="#section-1">1. Getting OO.o</a></li> + <li><a href="#section-2">2. Building OO.o</a></li> + <li><a href="#section-3">3. Installing OO.o</a></li> + <li><a href="#section-4">4. Running OO.o</a></li> + <li><a href="#section-5">5. Hacking OO.o</a></li> + <li><a href="#section-6">6. Debugging OO.o</a></li> + <li><a href="#section-7">7. Contributing patches</a></li> + <li><a href="#section-8">8. Misc. tips</a></li> + <li><a href="#section-9">9. Useful Links</a></li> + <li><a href="#section-10">10. IFAQ</a></li> + <li><a href="#section-11">11. Working with us</a></li> + </ul> + + <h2 id="section-1">1. Getting OO.o</h2> + + <p> + There are loads of versions of OO.o, and several choices of + branch, with multiple outstanding patch sets. + I recommend you build from up-stream CVS HEAD milestones + (SRC680 milestones), with patch sets to make them easier to + build from <a href="packages/SRC680">here</a>. + </p> + <p> + The very latest ooo-build (a small ~1.5Mb build wrapper) can + be got from CVS thus: + </p> + <pre> + export CVSROOT=':pserver:anonymous@anoncvs.gnome.org:/cvs/gnome' + cvs login + cvs -z3 checkout -P ooo-build + </pre> + + <p> + <strong>Note:</strong> You are going to need to download + an additional ~170Mb of compressed source, and have ~3Gb + of space space to unpack and build it in. + </p> + + <h2 id="section-2">2. Building OO.o</h2> + + <h3 id="section-2.1">2.1. configure</h3> + + <p> + The build process is pretty complicated; you have a choice + of commands now; although running both won't actually hurt: + </p> + <pre> + ./autogen.sh # only for the CVS version + ./configure # the packaged version + </pre> + <p> + This will guess which branch snapshot you want to build; if + you have other ideas use the --with-tag option; eg. + <code>--with-tag=src680-m65</code> for a legacy branch. + </p> + <p> + If for some reason you have a 31337 multi-threaded computer, + with great slabs of RAM; you'll want to use --with-num-cpus=8 + etc. NB. it's not clever to force the build to swap like a + demented pawnbroker by using an artificially high number; C++ + compilation is seriously memory hungry. + </p> + <p> + In particular, building SRC680 requires a recent jdk & a + version of apache-ant. If you use a Novell system, just do: + <code>sudo rug in apache-ant</code>, alternatively download + a package from <a + href="http://www.rpmfind.net/linux/rpm2html/search.php?query=apache-ant&submit=Search+..."> + rpmfind.net</a>, or failing that see + <a href="http://ant.apache.org/bindownload.cgi"> + Ant download</a> & set the ANT environment variable + appropriately before configuring. + </p> + + <h3 id="section-2.2">2.2 download</h3> + + <p> + By the time you've upgraded your system to the point that it + has all the packages you need to start building OO.o (mozilla, + recent libart etc. etc.) you're almost at the point that you + can download the bulk of the source. To do this, after a + successful configure simply type: <code>./download</code> and wait. + </p> + <p> + If for whatever reason this fails, you can verify your download + by fetching the equivalent .md5 file & comparing it to + the result of <code>md5sum <archive></code>. The source + archives are <a href="http://go-oo.org/packages/SRC680"> + here</a> - put the source in ooo-build/src. + </p> + + <h3 id="section-2.3">make</h3> + + <p> + This is the taxing bit - type <code>make</code> and don't forget + to press enter. Quite possibly you want to log the output, so + why not <code>make 2>&1 | tee /tmp/log</code>. + </p> + <p> + Since ooo-build wraps the actual OO.o configuration & + build process, there are a number of internal config checks that + also need to pass. For a first time build it's well worth staying + near the console while everything unpacks, and the internal + configure runs; if that completes without incident - you're + usually into the heavy-duty thumb twiddling. + </p> + + <h2 id="section-3">3. Installing OO.o</h2> + + <p> + When everything has finished building; you should get some happy + looking message. The easiest way to install is: + <code>bin/ooinstall -l <path-to-install-to></code> I often use + <code>/opt/OOInstall</code> + </p> + <p> + If you are a packager, you'll want to run <code>make install</code> + which honours DESTDIR & does other packager-like things. + </p> + <p> + <strong>Note:</strong> The '-l' to ooinstall runs a <a + href="#section-5.7">linkoo</a> on the installed result. + </p> + + <h2 id="section-4">4. Running OO.o</h2> + + <p> + Now wander into <code>/opt/OOInstall/program</code> and do: + <code>source ./ooenv</code> this will setup your (bash) shell for + running OO.o directly. Then simply <code>./soffice.bin -writer</code>. + This is better than running soffice, or a wrapper script since + it's very easy to use the debugger: <code>gdb soffice.bin</code>. + </p> + + <p> + <strong>Note:</strong> <code>ooenv</code> was formerly known as + <code>env</code>. It was renamed not to conflict with /usr/bin/env. + </p> + + <h2 id="section-5">5. Hacking OO.o</h2> + + <h3 id="section-5.0">5.0. My first hack</h3> + + <p> + So - we've built and run OO.o, and we want to prove to ourselves + that it is in fact possible to hack on it. So in a new terminal + do this: + </p> + <pre> + cd build/src680-m66 + . ./LinuxIntelEnv.Set.sh + cd vcl + </pre> + <p> + Now have a hack at vcl/source/window/toolbox2.cxx; I suggest + adding (eg.) an <code>nPos = 0</code> anywhere before the + m_aItems.insert in the 4rd InsertItem method: + <code>void ToolBox::InsertItem( USHORT nItemId, const XubString& rText, + ToolBoxItemBits nBits, USHORT nPos )</code>. + Then save. + </p> + <p> + You're still in vcl/ yes ? then type 'build debug=true'; wait + for the scrolling text to stop; (5 seconds?). Now re-run + <code>soffice -writer</code>. You should notice the effect. + If not, ensure the previous soffice.bin was dead with + <code>killall -9 soffice.bin</code> + </p> + <p> + You can find more things to hack in the <a href="tutorials">tutorials</a>. + </p> + <p> + <strong>Note:</strong> for day to day hacking you want to + just run 'build' inside the source tree. It is also highly + recommended to work inside a copy of the build tree, and + generate / test patches in an un-hacked version. + To copy just the build/src680-m66 directory elsewhere, you + need to use the <a href="#section-10.4">relocate</a> tool. + </p> + + <h3 id="section-5.1">5.1. Read the Fine manual</h3> + + <p> + With the power of C++ comes the ability to shoot yourself in the + foot all the more easily; (and implicitly), cf. <em>Holub, + Rules for C and C++ programming, McGraw-Hill, 95</em>. + </p> + + <p> + The best way to prepare yourself for battle is to read the + OpenOffice coding guidelines <a + href="http://tools.openoffice.org/CodingGuidelines.sxw"> + here</a>, and for the easily confused c'tor / d'tor is short for + constructor / destructor. + </p> + + <h3 id="section-5.2">5.2. Sending patches</h3> + + <p> + It is seldom clear which module a patch resides in in bugzilla. + A quick way to try and work this out is to do: + <code>cvs status <somefile> | head</code> + This should give a 'Repository Revision:' line, with a path, the + 2nd fragment of this is the project name, + <code>ooo-build/bin/owner</code> automates that process for you. + </p> + <p> + In addition, since the mapping of module names to IssueZilla + tickets is rather contorted & un-documented, if you know + what module the bug is in, use <a href="http://go-oo.org/bug.html"> + this</a> page to file it. + </p> + + <h3 id="section-5.3">5.3. Starting the right app</h3> + <p> + As you start soffice.bin, there are several useful parameters to + use to accelerate your debugging experience; particularly + <code>-writer</code>, <code>-calc</code>, <code>-draw</code>, + and (the wizardly painful) <code>-impress</code> arguments. + </p> + + <h3 id="section-5.4">5.4. Understanding D' make (man)</h3> + + <p> + While the build system is in similar to may other systems, it + is also perhaps slightly different. The overview is that each + module is <i>built</i>, and then the results are <i>delivered</i> + into the <a href="http://www.openoffice.org/dev_docs/source/solver.html"> + solver</a>. Each module builds against the headers + in the solver. Thus there are a few intricacies. + + <ul> + <li id="build"> + <i>build</i> — this perl script <i>solenv/bin/build.pl</i> is + used in conjunction with <a href="#section-5.4.2">prj/build.lst</a> + to ensure that every module that is needed is built first.<p> + build then un-winds internal module dependencies, and builds + each module with a chdir, dmake pair. + </li> + <li id="deliver"> + <i>deliver</i> — this perl script <i>solenv/bin/deliver.pl</i> + installs headers, and libraries (etc.) into the solver, as + informed by <a href="#section-5.4.3">prj/d.lst</a>. 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. + </li> + </ul> + </p> + + <h4 id="section-5.4.1">5.4.1 Standard directories</h4> + + <p> + There are various standard directories and files in most of the + modules that make up OO.o, here are some of the more useful: + + <ul> + <li><b>prj</b> + <ul> + <li> + <i>build.lst</i> — this lists directories to be made, + '^#' comments are allowed, the order of the list is + immaterial see <a href="#section-5.4.2">detail</a>, it + is dictates <i>build</i>'s operation. + </li> + <li><i>d.lst</i> — this file describes the <i>deliver</i> + process, see <a href="#section-5.4.3">detail</a>. + </li> + </ul> + </li> + <li> + <b>util</b> — 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 + <i>makefile.mk</i>, this is usually the last directory to be + built in a project. + </li> + <li> + <b>inc</b> — public headers are typically separated + into an 'inc' directory, these will be installed into + the solver by the 'deliver' phase (using <i>prj/d.lst</i>) + </li> + </ul> + </p> + + <p> + Build's mode of operation is to invoke 'dmake' in each of the + projects' directories with a given dependency order. dmake + then executes the rules in makefile.mk. + </p> + + <h4 id="section-5.4.2">5.4.2 build.lst</h4> + + <p> + On first view build.lst looks scary: + <pre> +vc vcl : NAS:nas FREETYPE: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 + </pre> + 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.<p> + + <ul> + <li> + 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. + </li> + <li> + Some modules have a CAPITALS:lowercase arrangement; the first + segment is a conditional, driven by a space delimited list in + the BUILD_TYPE environment variable at build time. + </li> + <li> + Then we have a redundant line 'usr1' [ for fun ? ], in fact + only lines containing the magic string 'nmake' are valid after + this. + </li> + <li> + The next lines describe internal project directory dependencies + and look like: + <pre> +[shortcut] [path to dir to build] nmake - [flags] [unique-name] [deps...] NULL +vc vcl\source\glyphs nmake - all vc_glyphs vc_unot NULL + </pre> + <i>shortcut</i> is not used; <i>flags</i> 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'.<p> + <i>unique-name</i> this is a magic name, used by other lines to + describe an internal dependency. <i>deps...</i> any number of names of + other directories in this file, that must be built before this one. + </li> + </ul> + So we see in the vcl case that <i>vcl\source\unotypes</i> (vc_unot) has + to be built before <i>vcl\source\glyphs</i> (vc_glyphs). It is + <b>important</b> 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. + <p> + There is also documentation <a href="http://tools.openoffice.org/tools/build.html"> + here</a> on it. + <p> + + <h4 id="section-5.4.3">5.4.3 d.lst</h4> + + <p> + The syntax of d.lst is more comprehensible than build.lst, it omits + some default actions, such as copying build.lst into + <i>inc/<module>/build.lst</i>.<p> + A line is of the form: + <pre> +[action]: [arguments] +mkdir: %_DEST%\inc%_EXT%\external + </pre> + where if '[action]:' is omitted, it defaults to the 'copy' action. + Typical actions are <i>copy</i>, <i>mkdir</i>, <i>touch</i>, <i>hedabu</i>, + <i>dos</i> and <i>linklib</i>.<p> + 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). + <p> + During the action, various macro variables are expanded some of which are: + <ul> + <li>%__SRC% — distribution directory name eg. <i>unxlngi4.pro</i></li> + <li> + %_DEST% — absolute path into solver eg. + <i>/opt/OpenOffice/OOO_STABLE_1/solver/641/unxlngi4.pro</i> + </li> + <li> + %_EXT% — (unusual) way of having minor updates eg. 641.1, + typically used to version every base sub-directory. + </li> + </ul> + Typically then, if indeed you need to add a rule (cf. implicit + directory copies), it will be of the form: + <pre> +..\%__SRC%\inc\sal\*.h %_DEST%\inc%_EXT%\sal\*.h + </pre> + NB. relative paths are relative to the 'prj/' directory. + </p> + + <h3 id="section-5.6">5.6 Can I get a <code>char *</code>, please?</h3> + + <p> + Just barely. OO.o has at least six string wrappers, although the C + implementations are of little interest: + </p> + + <ul> + <li> + <p> + <code>rtl_String</code> — sal/inc/rtl/string.h<br> + "Normal" string plus reference counting. + <code>rtlstring->buffer</code> is useful, as is + <code>rtlstring->length</code>. This object encapsulates + an generic 8bit string - of unknown encoding. Feel free to treat + <code>rtlstring->buffer</code> as your beloved <code>char *</code>. + If you really want to look at the implementation of some + <code>rtl_String</code> function and lxr nor grep can help you, have + a look at sal/rtl/source/strtmpl.c. + </p> + </li> + + <li> + <p> + <code>OString</code> — sal/inc/rtl/string.hxx<br> + Simply a rtl_String wrapped inside a <code>class</code>; you + can use <code>ostring.pData</code> to get at the rtl_String + (it's public). <code>OString</code> has reasonably useful + methods for if you need them. + </p> + </li> + + <li> + <p> + <code>rtl_uString</code> — sal/inc/rtl/ustring.h<br> + "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. + See <code>rtl_String</code> above to find where the implementation + of some <code>rtl_uString</code>functions is hidden. + </p> + </li> + + <li> + <p> + <code>OUString</code> — sal/inc/rtl/ustring.hxx<br> + An rtl_uString wrapped inside a <code>class</code>. This is + what most of the OO.o code uses to pass strings around. + To convert an <code>OString</code> to an <code>OUString</code> + it is necessary to specify the character set of the + <code>OString</code> see; <code>sal/inc/rtl/textenc.h</code> + — the only interesting case is <code>RTL_TEXTENCODING_UTF8</code> + </p> + </li> + + <li> + <p> + <code>String</code> — tools/inc/string.hxx<br> + This is an obsolete string class, aliased to 'UniString'. + It has a number of limitations such as a 64k length limit. + </p> + </li> + </ul> + + <p> + A couple of conversion functions are really useful here, + Particularly: + <p> + <p><code>rtl::OString aOString = ::rtl::OUStringToOString (aOUString, RTL_TEXTENCODING_UTF8);</code></p> + <p>And the reverse:</p> + <p><code>rtl::OUString aOString = ::rtl::OStringToOUString (aOString, RTL_TEXTENCODING_UTF8);</code></p> + + <p> + If you just want to programattically print out a string for + debugging purposes you probably want to see <a href="#printout"> + this</a>. + </p> + + <h4 id="section-5.7">5.7. Linkoo & Limitations</h4> + <p> + Linkoo is the tool that implements the <code>-l</code> + functionality of <code>bin/ooinstall</code>. It essentially + sym-links files of similar names into your local tree, + allowing a fast development iteration. + </p> + <p> + It is however slightly limited - some of the modules + cannot be linked for various reasons; these are: + <code>cppuhelper</code> and <code>configmgr</code>, + thus in the rare case that these are altered, they + must be copied manually into <code>/opt/OOInstall/program</code>. + </p> + <p> + In addition symlinks cannot be used for soffice.bin, and + this is more commonly altered - it has to be installed + from <code>desktop/unxlngi4.pro/bin/soffice</code> NB. + with an appended '.bin' + </p> + + <h2 id="section-6">6. Debugging OO.o</h2> + + <p> + This section assumes use of gdb, from the console. + </p> + + <h3 id="section-6.1">6.1. Building with debugging symbols</h3> + + <p> + OO.o includes a way to add debugging code in per module, via + the <code>build debug=true</code> command in each module. + This also adds lots of runtime assertions, + churning warnings etc. in addition to debug symbols - which + can be useful. To do just a plain build with debug symbols + though use <code>build debug=true dbg_build_only=true</code> + </p> + <p> + You can also configure OO.o with --enable-symbols to build + with symbolic generation. + </p> + + <h3 id="section-6.2">6.2. Starting at the beginning</h3> + + <p> + 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: + <pre> + p pImplSVData->maAppData + </pre> + This 'Main' method is typically: + desktop/source/app/app.cxx (Main). + </p> + + <h3 id="section-6.3">6.3. Examining strings</h3> + + <p> + We have already <a href="#section-5.6">seen</a> that OO.o has + it's own set of string classes, none of which gdb understands. + You need to use: + <code>(gdb) print dbg_dump(sWhatEver)</code> to print the contents + of a UniString/ByteString/rtl::OUString/rtl::OString regardless + of the type when debugging C++ code. See Caolan's write-up + <a href="http://www.skynet.ie/~caolan/TechTexts/GdbUnicodePrinting.html"> + here</a> for details. + </p> + + <h3 id="section-6.4">6.4 Getting the build order right</h3> + + <p> + 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: + <pre> +xh neon : soltools external expat NULL + </pre> + 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. + </p> + + <h3 id="section-6.5">6.5 It crashes, but only in gdb</h3> + + <p> + 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. + </p> + + <h3 id="section-6.6">6.6 It crashes, but doesn't crash</h3> + + <p> + For various reasons signal handlers are trapped and life + can get rather confusing; thus it's best for builders to + apply something like this: +<pre> +--- 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; + +</pre> + NB. trailing space. + </p> + + <h3 id="section-6.7">6.7 I can't find the code from the trace</h3> + + <p> + 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. + <pre> + IMPL_LINK( Window, ImplHandlePaintHdl, void*, EMPTYARG ) + </pre> + builds the 'LinkStubImplHandlePaintHdl' method. + </p> + + <h3 id="section-6.8">6.8 How can I re-build just the files I see in the trace</h3> + + <p> + Often when you run gdb on a build without debugging symbols, you get + an unhelpful gdb trace, but yet you can't afford the time/space to + recompile all of OO.o with debugging symbols. Thus we have created + a small perl helper, which will hunt for & touch files containing + the symbols from your trace. This sub-set can then be re-built with + debugging enabled for a better trace next time around: + </p> + <pre> + 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<com::sun::star::document::XImporter> const*) () from ./libsfx641li.so +... + quit + cd base/OOO_STABLE_1/sfx2 + ootouch SfxMedium + build debug=true + </pre> + <p> + Thus, all files referencing / implementing anything with + SfxMedium will be touched, and hence rebuilt with debugging + symbols. + </p> + + <h3 id="section-6.9">6.9 How can I re-build all the files in one source directory</h3> + + <p> + If you want to recompile the code in just your current directory, you can + use the killobj dmake target to remove the object files: + </p> + <pre> + dmake killobj + dmake + </pre> + + <h3 id="section-6.10">6.10 It always crashes in sal_XErrorHdl</h3> + + <p> + You are a victim of asynchronous X error reporting; + <code>export SAL_SYNCHRONIZE=1</code> will make all the X traffic + synchronous, and report the error by the method that caused it, + it'll also make OO.o far slower, and the timing different. + </p> + + <h3 id="section-6.11">6.11 It silently fails to load my word file</h3> + <p> + Caolan suggests: put breakpoints in ww8par.cxx top and tail of + SwWW8ImplReader::LoadDoc, and confirm that the document gets as far + as the import filter. + </p> + <p> + A handy human place to put a breakpoint is in + SwWW8ImplReader::ReadPlainChars, you can see chunks of text as + they are read in. Alternatively SwWW8ImplReader::AppendTxtNode as + each paragraph is inserted. + </p> + + <h3 id="section-6.12">6.12 How do I use the debug console ?</h3> + <p> + So OO.o contains some hefty debugging infrastructure; pictured + <a href="images/debug-window.png">here</a>. Unfortunately + enabling it is not altogether trivial. Firstly - none of it is built + into a product build; so we need to go to re-build some core parts + of OO.o as non-product builds; and then we need to re-run linkoo + to link those new builds into our set. + </p> + <p> + First create a debug Environment file; I call it +LinuxIntelEnv.Set.debug: +<pre> +TMPFILE=~/.Env.Set.debug + +# Purge .pro bits +sed 's/\.pro//g' LinuxIntelEnv.Set.sh > $TMPFILE +. $TMPFILE +rm $TMPFILE + +# Clobber product parts +unset PRODUCT PROSWITCH PROFULLSWITCH +</pre> + Now do <code>source ./LinuxIntelEnv.Set.debug</code>, this + sets up your environment for a non-product build. + </p> + <p> + cd vcl; build dbgutil=true --all + linkoo <install-path> <here> + </p> + <p> + Now - just run OO.o, and when it's in full-flow, press + <Alt>-<Shift>-<Control> 'D' in that + order; this should popup a debugging options window. + The debugging options + are subsequently saved to the .dbgsv.init file for the + next run; you can control the location of that with: + <code>export DBGSV_INIT=$(HOME)/.dbgsv.init</code> eg. it + is (unfortunately) a binary file. + </p> + + <h3 id="section-6.13">6.13 Excel Interop debugging</h3> + <p> + This is fairly easy; edit sc/source/filter/inc/biffdump.hxx, + define EXC_INCL_DUMPER to 1, and re-build 'sc'. Also, copy + sc/source/filter/excel/biffrecdumper.ini to ~. Then run + <code>soffice.bin foo.xls</code> and you should get a + foo.txt with the debug data in it. + </p> + + <h3 id="section-6.14">6.14 The trace shows a crash in 'poll'</h3> + <p> + OO.o is a fairly threaded program, you're prolly just looking + at the wrong thread: there are not likely to be bugs in poll. + Use <code>thread apply all backtrace</code> to get a backtrace + of all threads - this will most likely fail. When it does do: + <code>thread 1</code> then <code>bt</code> - most crashers + occur in the 'main' thread. + </p> + + <h3 id="section-6.15">6.15 What does this trace mean ?</h3> + <p> + There are several typical stack-traces that come up again + and again, one would be: + </p> + <pre>#15 0x4164a501 in raise () from /lib/tls/libc.so.6 +#16 0x4164bcd9 in abort () from /lib/tls/libc.so.6 +#17 0x415fb5a5 in std::set_unexpected () + from /home/mnagashree/m72install/program/libstdc++.so.5 +#18 0x415fb5e2 in std::terminate () + from /home/mnagashree/m72install/program/libstdc++.so.5 +#19 0x415fb69c in __cxa_rethrow () + </pre> + <p> + This section of trace means (essentially) that an + exception was thrown - but there was no-one trying to + catch it. Often this means there was a missing + 'try {} catch()' clause in one of the calling frames. + </p> + <p> + A great way to debug exceptions is to add a breakpoint + in catch/throw, do this with <code>catch throw</code> or + <code>catch catch</code> in gdb. + </p> + + <h2 id="section-7">7. Contributing patches</h2> + + <h3 id="section-7.1">7.1. Diff style</h3> + + <p> + Always use unified diffs 'cvs -z3 diff -u', since they are the + most readable, (and sensible) types of diff to read and apply. + </p> + + <h3 id="section-7.2">7.2. Some interaction</h3> + + <p> + It tends to be a good idea to work out how best to implement + your fix, and/or discuss it with a developer or two before hand. + Some of the best ways to do this are to post to <a + href="mailto:dev@openoffice.org">dev@openoffice.org</a> or lurk + on IRC at <tt>irc.freenode.net</tt> on the + <tt>#OpenOffice.org</tt> channel. IRC is an awfully poor + communication medium, but better than no communication. + See <a href="name-account.html">here</a> to unwind who is + whom. + </p> + + <h3 id="section-7.3">7.3. ooo-build patch creation</h3> + <p> + See <a href="ooo-build.html#section-2.2">here</a> for more + information on our patching infrastructure. + </p> + + <h3 id="section-7.4">7.4 filing bugs</h3> + <p> + See <a href="bug.html">here</a> for a sane / hackers interface + to OpenOffice's IssueZilla. + </p> + <p id="owner"> + Since we can often extract the owner of a module by checking + for the ADMIN_FILE_OWNER tag; there is a little tool in + ooo-build: bin/owner <file-name> that helps you + find out who to E-mail / interact with about a given module; + it's worth assigning very specifically located bugs to that + person. + </p> + + <h2 id="section-8">8. Misc. tips</h2> + + <h3 id="section-8.1">8.1. Getting an OO.o CVS account</h3> + + <p> + This is the process for getting CVS accounts for the up-stream + CVS server, ooo-build accounts are handled <a + href="ooo-build.html#section-2.5.1">differently</a>. To see how + the issue raising process works see eg. issue <a + href="http://www.openoffice.org/issues/show_bug.cgi?id=7270">#7270</a>. + Having got the account setup, you need to tunnel to the secure CVS server + something like: + </p> + + <p><code>ssh -f -2 -P -L 2401:localhost:2401 tunnel@openoffice.org sleep 1400 < /dev/null > /dev/null</code></p> + + <p> + Then you need to change your CVSROOT to point at your local + machine, since this is the endpoint of the tunnel: + </p> + + <p><code>:pserver:mmeeks@localhost:/cvs</code></p> + + <p> + Your account name and password - will be the same as you use for + filing bugs etc. in the SourceCast system. Login, and ... you'll + soon notice that you'll need to migrate your CVS settings to the + new server, to do this without wasting B/W with duplicate + checkouts do: + </p> + <code>bin/re-root /path/to/checkout ":pserver:<account-name-here>@localhost:/cvs"</code> + <p> + Of course, to commit anything, you'll need various project + priviliges - and to battle the bureaucracy. + </p> + + <h3 id="section-8.2">8.2 Using patch / diff</h3> + + <p> + Patch/diff are a wonderful tools, however people often provide + data that confuses them in a messy and difficult to un-tangle + sort of a way. Here are some hints on untangling the mess: + </p> + <ul> + <li>If at all unsure, run patch with --dry-run first, this will + appear to do the patching action, but not actually do it + [ this can give bogus results with compound inter-depending + patches, but is extremely useful ]. + <li>Mostly use patch -p0; 0 signifies the number of path + elements to strip from the beginning of the file path the + diff points at. + <li>When you mess up, and have 1/2 of the patch applied and want + to revert to clean, either remove the files and cvs update, + or re-patch with the '-R' option, to reverse the effect. + <li>Sometimes using diff between modules with lots of whitespace + changes makes the patch hard to read; the '-w' flag to (cvs) + diff makes this easier. + </ul> + <p> + Before committing a patch to ooo-build, test it with + <code>make patch.apply</code> in the top-level, NB. it really + pays to have 2 copies of the tree - 1 hacked, 1 pristine. + </p> + + <h3 id="section-8.3">8.3 Make clean</h3> + + <p> + Just use <code>dmake clean</code> in the <code>build/src680</code> directory. + Or for a more descructive version in ooo-build try <code>rm -Rf build</code>. + </p> + + <h3 id="section-8.4">8.4 CVS setup</h3> + + <p> + In order to make efficient use of bandwidth, generate sensible + diffs by default, and follow the trend, you need this in your + ~/.cvsrc. + </p> +<pre> +cvs -z3 -q +diff -upN +update -dP +checkout -P +status -v +</pre> + + <h3 id="section-8.5">8.5. Adding header files to the build</h3> + + <p> + Adding header files to the OO.o build is notoriously clunky. To + add header files under <code>external/</code>, make sure you list them in + <code>external/prj/d.lst</code> so that they get copied under the + <code>solver/680/unxlngi4.pro/inc/external</code> directory when building. + </p> + + + <h3 id="section-8.6">8.6. Finding where to hack</h3> + + <p> + 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 <a href="http://go-oo.org/lxr">LXR</a>'s + <b>text</b> 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: ... + </p> + + <h4 id="section-8.9">8.9. Adding an UNO interface</h4> + <p> + This is slightly more complex build wise than you might expect. + <ul> + <li>Add IDL file to offapi/com/sun/star/wherever/Foo.idl. + <li>If 'wherever is <i>not</i> a new path, add Foo.idl to + IDLFILES in wherever/makefile.mk. + <li>If 'wherever' <i>is</i> a new path, update offapi/util/makefile.mk to + refer to the relevant TARGET .db, prolly 'whatever.db'. + <li>If 'wherever' <i>is</i> a new path, update offapi/prj/d.lst and + build.lst appropriately. + </ul> + </p> + <p> + This should result in your type information being built into + types.rdb & installed. This is however only part of the mix: + the module 'offuh' builds & installs the .hdl/.hpp files we + need (for C++), so if 'wherever' is a new path we need to update + offuh/prj/d.lst to install those files too. + </p> + <p> + Finally, check that the types.rdb in the install set has your + types; a <code>regview types.rdb / | grep 'whatever' -i</code> + would work well for that. If not, copy it in from the solver. + </p> + + <h2 id="section-9">9. Useful links</h2> + + <h3 id="section-9.1">9.1. www.OpenOffice.org</h3> + + <p> + While much of the initial openoffice.org structure seems not to + be orientated towards hackers, there is much useful <a + href="http://www.openoffice.org/documentation.html"> + documentation</a> if you dig for it. + </p> + + <p> + For OO.o news, and a distinctive perspective on OO.o see + <a href="http://www.ooodocs.org">ooodocs.org</a>. + </p> + + <p> + Other related pages are: + + <a href="http://ooextras.sourceforge.net">OOExtras</a> provides + extra templates, macros, and clip art (curiously licensed under the LGPL). + + <a href="http://ooqstart.sourceforge.net">Quickstart applet</a> for GNOME + (and <a href="http://segfaultskde.berlios.de/index.php?content=oooqs">KDE</a>). + + <a href="http://dict.progbits.com">Dictionaries & Docs</a> from Kevin Hendricks. + <p> + + <p> + And an interesting <a href="http://www.kaaredyret.dk/openoffice_links_uk.html"> + portal</a>. + </p> + + <h3 id="section-9.2">9.2. Patch archives</h3> + + <p> + While productising various releases of OpenOffice, different + projects have come up with (quite huge) patch sets against OO.o. + These have mostly been folded back into 2.0 but, there are still + a few outstanding. The separate packaging efforts can be found here: + </p> + + <ul> + <li> + <a href="http://go-oo.org">go-ooo</a> Lots of our OO.o patches + and build tools / snapshots are available here. + </li> + <li> + <a href="http://www.debian.org">Debian</a>'s helpful OO.o <a + href="http://www.linux-debian.de/openoffice/">page</a>, with + patches. And also Debian <a + href="http://cvs.debian.org/oo-deb/debian/?cvsroot=debian-openoffice"> + CVS</a>. + </li> + <li> + <a href="http://www.linux-mandrake.com">Mandrake</a>'s OO.o <a + href="http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/SPECS/OpenOffice.org/"> + patch archive</a>. Mandrake do an appallingly bad job of working + with either the ooo-build or openoffice.org community. + </li> + <li> + <a href="http://www.freebsd.org/cgi/cvsweb.cgi/ports/editors/openoffice/#dirlist"> + FreeBSD</a>'s OO.o port patches. + </li> + <li> + <a href="http://fedora.redhat.com">Fedora</a>'s OO.o 2.0 <a href="http://cvs.fedora.redhat.com/viewcvs/devel/openoffice.org/">patch archive.</a> + </li> + </ul> + + <h2 id="section-10">10. (Infrequently) FAQ</h2> + + <p> + So no-one ever asked me these, I just made them up to astro-turf + a bit (safer, wipe-clean, more durable questions). + </p> + + <h3 id="section-10.1">10.1. Why do branches like 'mws_srx645' have odd numbers in them ?</h3> + + <p> + By consulting various oracles, entrails etc. it transpires that + in theory this number once incremented weekly, there being weekly + freezes and hence solvers, development environments. + The 'mws' stands for 'Master Workspace'. The latest 2.0 development + is done with the SRC680 stem; with auto-incrementing milestones; hence + tags like <code>SRC680_m66</code> would be common. + </p> + + <h3 id="section-10.2">10.2. Why does the <b>build</b> require Java ?</h3> + + <p> + Essentially it seems there are a lot of XML files involved in + component registration, and various other services. Also, the person + who designed the XML files fell in love with trendy XML-things and + used not-very-standard, very complicated bits gratuitously. It turns + out that using Java is the best/only way to get this manipulation + done. Also, Java can be used nicely at run-time if it's on the machine. + </p> + <p> + But from tag SRC680_m44 onwards there is an + <a href="http://www.openoffice.org/issues/show_bug.cgi?id=28773"> + alternative python script</a> included to address the issue of processing + these XML files used for registration, so it should be possible to build + versions after that date without java, though your milage may vary as the + default build is with java. + </p> + + <h3 id="section-10.3">10.3. Why is [t]csh so broken ?</h3> + + <p> + This is rather inscrutable; some particularly curious brokenness + would be the way piping commands on stdin is crucially different + to inputting them from the tty thus: + <code>echo 'echo #define DLL_NAME "libsch641li.so" >./foo.hxx' | /bin/tcsh -s</code> + fails to do anything whereas typing the same thing into the shell + works just fine. Even more oddly: + <code>tcsh -fc 'echo #define DLL_NAME "libsch641li.so" >./foo.hxx'</code> + does do the right thing. See also <a + href="http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/">csh</a>. + </p> + + <h3 id="section-10.4">10.4. I just tried to re-locate the build, why doesn't it work ?</h3> + + <p> + The simple answer is: you need to run <code>relocate /path/to/new/build</code>; + another more complex answer is: + </p> + <p> + Well, <b>assuming</b> 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: + <code>find -name '*.dpc*' -exec rm {} \;</code> + </p> + <p> + The stlport does some really <a href="#section-10.10">broken</a> 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). + </p> + + <h3 id="section-10.5">10.5 CVS says 'Fatal Error aborting. [acc] no such user', why ?</h3> + + <p> + While of course it's possible that your user name is not registered; often + this just means your ~/.cvspass got lost and/or that you haven't logged in. + cvs login, and repeat the command. + </p> + + <h3 id="section-10.6">10.6 What does '.pro' in 'unxlngi4.pro' mean ?</h3> + + <p> + <i>Pro</i>duct — isn't it obvious ? + </p> + + <h3 id="section-10.7">10.7 What does OpenOffice really look like ?</h3> + + <p> + Today I found a photograph of it on my system, so I stuck it in here: + </p> + <img src="images/layers.png" alt="Abstraction Layers"> + + <h3 id="section-10.8">10.8 How do I take a screenshot of OO.o ?</h3> + <p> + OOo does some very odd things with X resources, thus some conventional + screenshot apps fail to take accurate shots. ImageMagick's 'import' + however does a good job; use: + <code>import foo.png</code> from the console, or + <code>sleep 2; import -window root foo.png</code> instead. + NB. unless you want your world to look tiny, you need to turn large + toolbar icons first. + </p> + + <h3 id="section-10.9">10.9 Why does the code look so ugly?</h3> + <p> + The authors must be using a really strange editor. + It <em>thinks</em> tab stops are on every fourth column. + Of course, the files come out ugly in Unix editors which <em>know</em> + that tabs are eight characters wide. + </p> + <p> + If you happen to use + <a href="http://www.gnu.org/software/emacs/">a Real Editor</a>, + we have some pink glasses to sell to you. Paste the contents of + <a href="http://go-oo.org/emacs.el">http://go-oo.org/emacs.el</a> + into your <tt>.emacs</tt>, + or load it with a line like this: <tt>(load "/path/to/that/file.el")</tt>. + Don't forget to adapt <tt>my-openoffice-path-regexp</tt> to your needs. + </p> + <p> + Henceforth emacs will use 4-column tabs for your OOo source files. + (And use <em>C++-Mode</em> for <tt>sdi</tt>-, <tt>hrc</tt>-, + and <tt>src</tt>-files.) Alternatively if you are sufficiently set in + your ways that you can't cope with investing these few seconds do: + <code>M-x set-variable\ntab-width 4</code> & learn to love change. + </p> + <p> + Apparently if you use vi you can do: <code>:set ts=4</code>, and + good luck to you. + </p> + + <h2 id="section-11">11. Working with us</h2> + <p> + See the <a href="ooo-build.html">About ooo-build</a> document. + </p> + + <hr> + <p>If you have more hacking tips, corrections, a grip of correct + spelling etc. please do mail <a href="http://www.gnome.org/~michael">me</a>, + at <a href="mailto:michael.meeks@novell.com">michael.meeks@novell.com</a>.</p> + </body> +</html> diff --git a/developers/index.php b/developers/index.php index 21e600e..0b78587 100644 --- a/developers/index.php +++ b/developers/index.php @@ -82,12 +82,12 @@ print_page("Go-OO! - Developers", "developers", " <li><a href=\"tutorials\">Hackers Tutorials</a></li>". " <li><a href=\"cws.html\">Hackers CWS howto</a> & <a href=\"cws-quickhowto-ja.html\">Japanese</a></li>". " <li><a href=\"http://wiki.services.openoffice.org/wiki/Ooo-build\">About ooo-build</a></li>". -" <li><a href=\"users-faq.html\">Users' FAQ</a></li>". +" <li><a href=\"/users/faq/\">Users' FAQ</a></li>". " <li><a href=\"http://wiki.services.openoffice.org/wiki/DomainDeveloper\">Who is Whom?</a></li>". " <li><a href=\"http://eis.services.openoffice.org/EIS2/servlet/GuestLogon\">EIS</a></li>". " <li><a href=\"http://wiki.services.openoffice.org/wiki/Tinderbox_Setup\">Tinderbox setup</a></li>". " <li>ooo-build <a href=\"packages\">source</a> & <a href=\"patches\">patches</a></li>". -" <li><a href=\"mgp-users.html\">MagicPoint users</a></li>". +" <li><a href=\"/users/mgp/\">MagicPoint users</a></li>". " </ul>". " </dd>". " </dl>". diff --git a/developers/old-guides.html b/developers/old-guides.html new file mode 100644 index 0000000..8cd7644 --- /dev/null +++ b/developers/old-guides.html @@ -0,0 +1,30 @@ +<html> +<head> +<title>Older OpenOffice.org build guides</title> +</head> +<body> +<h1>Older OpenOffice.org build guides</h1> + +<h3><a href="detailed-build-guide.html">The detailed build guide</a></h3> +<p> + + Details the build process of 1.0.x (& partially relevant to 1.1.x) + in gruesome detail - hopefully it's mostly obsolete by now, particularly + wrt. the use of ooo-build. +</p> + +<h3>Older 1.1.x targetting guides</a></h3> +<p> + These provide an obsolete & unmaintained view into building +and developing with the OO.o 1.1.x builds, using the ooo-build-1.3.x +releases. +</p> +<p> + <ul> + <li><a href="hackers-guide-1.1.html">English</a></li> + <li><a href="hackers-guide-1.1-ja.html">Japanese</a></li> + <li><a href="hackers-guide-1.1-de.html">German</a></li> + </ul> +</p> +</body> +</html> |