Tips

From Apache OpenOffice Wiki
Revision as of 11:32, 21 November 2005 by Michael (Talk | contribs)

Jump to: navigation, search

Getting an OO.o CVS account

This is the process for getting CVS accounts for the up-stream CVS server, (ooo-build accounts are handled differently). To see how the issue raising process works see eg. issue i#7270# Having got the account setup, you need to tunnel to the secure CVS server something like:

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

Then you need to change your CVSROOT to point at your local machine, since this is the endpoint of the tunnel:

:pserver:mmeeks@localhost:/cvs

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:

   bin/re-root /path/to/checkout ":pserver:<account-name-here>@localhost:/cvs"

Of course, to commit anything, you'll need various project priviliges - and to battle the bureaucracy.

 == Using patch / diff ==

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:

  • 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 ].
  • Mostly use patch -p0; 0 signifies the number of path elements to strip from the beginning of the file path the diff points at.
  • 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.
  • 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.

Before committing a patch to ooo-build, test it with make patch.apply in the top-level, NB. it really pays to have 2 copies of the tree - 1 hacked, 1 pristine.

Make clean

Just use dmake clean in the build/src680 directory. Or for a more descructive version in ooo-build try rm -Rf build.

CVS setup

In order to make efficient use of bandwidth, generate sensible diffs by default, and follow the trend, you need this in your ~/.cvsrc.

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

Adding header files to the build

Adding header files to the OO.o build is notoriously clunky. To add header files under external/, make sure you list them in external/prj/d.lst so that they get copied under the solver/680/unxlngi4.pro/inc/external directory when building.


Finding where to hack

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

Adding an UNO interface

This is slightly more complex build wise than you might expect.

  • Add IDL file to offapi/com/sun/star/wherever/Foo.idl.
  • If 'wherever is not a new path, add Foo.idl to IDLFILES in wherever/makefile.mk.
  • If 'wherever' is a new path, update offapi/util/makefile.mk to refer to the relevant TARGET .db, prolly 'whatever.db'.
  • If 'wherever' is a new path, update offapi/prj/d.lst and build.lst appropriately.

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.

Finally, check that the types.rdb in the install set has your types; a regview types.rdb / | grep 'whatever' -i would work well for that. If not, copy it in from the solver.

Creating a new top-level module

See here

Personal tools