From Apache OpenOffice Wiki
Jump to: navigation, search

Getting an OO.o CVS account

Book-old.png    This article is outdated.    
Documentation note.png For development on the current development line, no CVS is needed. DEV300 is currently hosted on Mercurial, while releases up to 3.2 are hosted on Subversion.

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


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

  • When creating diffs, please use diff -upN to create a diff against the revision(s) you checked out.
    The options used are:
    Create unified context diff.
    Chances are much higher that the patch reviewer sees what it is about and is able to apply the patch to code that changed in the meantime.
    Show which C function each change is in.
    Just informational, be nice to the patch reviewer.
    New file, treat absent files as empty,
    which effectively includes new files in your diff that otherwise would be missing.
  • 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/ 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/
  • If 'wherever' is a new path, update offapi/util/ 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 for technical details about bringing external code into the OOo build environment. How to handle new modules in the Childworkspace process is described in this CWS-HowTo.

Find out which OOo version you are using

Open up the About dialog (last entry in the help menu) what gives the internal milestone number, plus the build ID.

saving disk space by linking to the solver only

Use "--dlv_switch -link" when running build to tell deliver to only link the files instead of copying them:

build --dlv_switch -link

See also

Personal tools