Thorsten Behrens
Email: <thb AT SPAMFREE openoffice DOT org>
I blog here
My ooo-build workflow
This is my workflow, so if you blindly copy it - YMMV (and thanks to erAck for the blue print of this).
Install openSuse. Do this in the given order:
zypper si -d OpenOffice_org-bootstrap (from here)
cd <spacious_disk>; git clone ssh://thorsten@git.freedesktop.org/git/ooo-build/ooo-build (from here)
cd ooo-build; ./autogen.sh --with-distro=SUSE-11.1 --with-gcc-speedup=ccache --disable-dependency-tracking --disable-mozilla --without-system-mozilla --with-num-cpus=2 --with-git --with-git-managed
./download && make && make dev-install && make gitignore && make id (has already prepared mkid database for all of the codebase. See Emacs stuff)
- gets you a readily hackable OOo install in ooo-build/build/install
for actually compiling stuff, I use screens - they so nicely make environment persistent, which the build system still relies a lot on, sadly
cd build/<XYZ_the_version>/ && screen -S ooo-build followed by source LinuxIntelEnv*.sh inside the screen
say, you need to debug something inside sd module - do this to get debug symbols:
screen -d -r ooo-build (if not attached already)
cd sd && rm -rf unxln* && build -P2 debug=t
- when done, start the installed office from ooo-build/build/install/program/soffice.bin (it uses the binaries directly from the build tree, no need to re-install or somesuch)
like this: cd ooo-build/build/install/program; source ooenv and then e.g. ./soffice.bin -norestore -impress
- when you fixed something, again maybe in sd, it's almost the same:
screen -d -r ooo-build (if not attached already)
cd sd && build -P2 debug=t
- when done, start the installed office from ooo-build/build/install/program/soffice.bin (it uses the binaries directly from the build tree, no need to re-install or somesuch)
in fact, I usually build from inside my emacs, because it makes jumping to the lines with the compiler errors much easier.
now, when hacking on stuff, I frequently need to generate & shuffle patches, so I do this:
cd build/<XYZ_the_version>/ && stg init
- which gives me a stacked git repo, that I use like this:
- new bug comes in
stg new my-new-patch-name
- fix fix fix
stg refresh
stg export -O --no-prefix -s my-new-patch-name > ../../patches/dev300/my-new-patch-name.diff
add patch to ooo-build/patches/dev300/apply file, review, git commit it
of course, one is frequently interrupted, so then, to shelve the my-new-patch-name stuff, first refresh it from your working tree, then use stg push/stg pop and friends to quickly switch to another patch
for debugging, I simply refer you to erAck, not much to add here, except this:
my .gdbinit file
I prefer starting ooo from within gdb, setting breakpoints in libs not yet loaded works best via break filename.cxx:1234, or using the history from a previous run, where you've used the symbol completion function (read the section about the c++ specifics there) when the code was loaded
remember to source ooenv before starting gdb
I prefer having gdb and OOo running on different displays; especially when debugging UI code, one often ends up in endless repaint loops or locked screens (due to mouse grabs). Use xnest or Xephyr when only one physical screen is available; apply ooo-build/patches/dev300/vcl-disable-mouse-grab.diff and export SAL_NO_MOUSEGRABS=TRUE to make it at least bearable on a single display
The Inner Loops
Getting a fresh build (usually because the underlying upstream milestone has changed):
cd ooo-build; make clean-local; git pull -r; ./autogen.sh (autogen will reuse the args used last time)
./download && make && make dev-install && make gitignore && make id
Getting a fresh build (the continuous integration way):
cd ooo-build; ./bin/tinbuild
- this will continually pull new versions and build them
Fixing a bug:
- fix fix fix
press F12 in xemacs, on the .cxx file you've changed (the std make cmd is preset to oob here, which I usually extend to oob debug=t (more))
- when done, start the installed office from ooo-build/build/install/program/soffice.bin (it uses the binaries directly from the build tree, no need to re-install or somesuch)
Wet Dreams
- make uno component unloading actually work
fix bug, recompile component lib, call rtl_unloadUnusedModules(0) in a gdb running OOo, re-execute functionality that exercises uno component
- feel on par with XCode
- any takers?