- 1 Getting an OO.o CVS account
- 2 Using patch / diff
- 3 Make clean
- 4 CVS setup
- 5 Adding header files to the build
- 6 Finding where to hack
- 7 Adding an UNO interface
- 8 Creating a new top-level module
- 9 Find out which OOo version you are using
- 10 saving disk space by linking to the solver only
- 11 See also
Getting an OO.o CVS account
|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 firstname.lastname@example.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:
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 -upNto 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.
dmake clean in the
Or for a more descructive version in ooo-build try
rm -Rf build.
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
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.
Use "--dlv_switch -link" when running build to tell deliver to only link the files instead of copying them:
build --dlv_switch -link