Pro Git

I've just learned about the Git book - Pro Git. I've read just small parts of that, but looks really great :-) You can buy a printed version of that too.

Split build

Split build is an effort to provide OpenOffice.org buildable by pieces; and additionally the way you can see with all the free software projects that use autotools - just ./configure ; make ; sudo make install.

But what I mean by 'building by pieces'? Imagine you are completely new to OOo development, and notice a tiny misbehavior in Calc. What do you have to do now? Download all the giant monolithic sources, guess the right configure switches, install all the dependencies, learn the OOo build system, and do the build. If you did not get demotivated by now, you might try to fix the original problem.

ooo-build makes it a bit easier - it has default settings for lots of the distros out there, and automates the download of the sources. But the ultimate answer is the split build :-)

With the split build [when finished, of course ;-)], all you'll have to do is install the OpenOffice.org-*-devel packages using the way usual for your distro (in openSUSE, it will mean zypper source-install -d OpenOffice_org-calc, in Debian apt-get build-dep packagename), clone the Calc tree, and do ./configure (or ./autogen.sh to generate the autotools stuff) ; make .

At the moment, it is work in progress, taking place in the ooo-build git repositories. So far, bootstrap (the common build pieces), ure (UNO Runtime Environment), libs-extern (3rd party libraries), and libs-extern-sys (3rd party libraries, usually available in recent Linux system) are in usable shape, more to come soon.

Oh yes, and for those who still want to build everything, there will be a possibility to do make world in bootstrap that will build everything from the beginning to the end :-)

OOo KDE4 Integration

Thanks to the heroic efforts of Éric Bischoff, Bernhard Rosenkränzer, and Roman Shtylman, the OpenOffice.org KDE Integration has been ported to KDE4. It still has some rough edges (currently the detection does not work out of the box—you have to export OOO_FORCE_DESKTOP=kde4 to get it), but it is safe because it co-exists nicely with the existing KDE3 integration; so if you are not satisfied, you are able just swich back to KDE3 (export OOO_FORCE_DESKTOP=kde).

For KDE4, Roman is also changing the out-of-process implementation of the KDE file picker to an in-process implementation, so you'll probably notice some performance improvement of the KDE file dialog launch too :-)

Guys, thank you!

Yet another SVN to git conversion tool

Recently I needed to convert the ooo-build repository from the Gnome SVN to git, and also create a regularly updated git mirror of the OpenOffice.org SVN repository. Unfortunately I did not find a tool that would suffice my needs - git-svn was unable to handle more branches, and svn-all-fast-export had a Qt4 dependency that made it problematic to even compile, not to mention the syntax of the repository description file(s) that I did not really understand - so I decided to create a new tool based on svn-fast-export.c:

http://cgit.freedesktop.org/ooo-build/contrib/svn-to-git

I made it for our needs, so there is just a simple Makefile, the code might be hacky here and there [and is C++ ;-)], but it seems to work really well - at least for us :-)

Features:

• perfect import of trunk (master), branches and tags
  even when you svn cp things around like svn cp branches/blah/bleh trunk/foo/bar
  when there are commits to the tags
• change login names to real names and email addresses
• converts ChangeLog-like commit messages to git-like
  (optionally)
• allows you to split one SVN tree to multiple git trees
  (based on regexps)
• allows you to convert leading tabs to spaces in files you choose
  (fixes a terrible pain in the OOo sources where tab is set to 4 spaces, and leading tabs and spaces are combined in nearly every source file!)
• allows you to ignore broken tags/commits
• and is really fast
  the OOo SVN with ~270000 commits in < 1hr on the right H/W ;-)

Documentation is a bit lacking, but basically you need to create one file containing the description of the repositories, and one with the names/emails of the svn login names, and you are ready to start ./svn-to-git.sh. Description files I used for the ooo-build and OOo conversions are included.

So - if you are interested, and have a SVN repository to convert, give it a try. And if you have patches, please send them to me :-)

Is git hard to use?

As you might know, ooo-build has switched to git a month ago. After the month of real use, I think we can say that no, git is not hard to use. But check an example git session and answer yourself :-)

And if you want to know more about the git usage, check the complete ooo-build GettingIt pages. Don't worry, it won't take you more than 10 minutes...

Even you can fix your favorite bug in OOo!

Last weekend I had a presentation called Even you can fix your favorite bug in OOo! (Czech only) at Linux Weekend (Czech only). Not that it was a favor to Dan Ohnesorg who kindly provided the bandwith and service for the video streaming from the GoOOCon 2008, it was also a good opportunity to sort the stuff that one needs to get started fixing a bug in OOo. In the end, I was talking the entire hour more or less just about how to get a build, and nearly no time was left to talk about the actual debugging.

The situation would be a lot simpler if we used more standard tools - but due to the OOo roots, all of them are self-baked. Starting with configure located inside a directory, through self-patched dmake, across build.pl and deliver, to gsi files etc. And all this so monolithic that any bigger change has to touch everything, or the change was not big enough ;-)

For quite some time, I think of splitting the OOo compilation into smaller parts. Yes, the 'divide et impera', so that the changes are smaller, easier to achieve, faster to build. It would also alow nicer -devel packages in the Linux distros. Now when I see its importance again, and more brightly, Petr or me will try to achieve it in Go-oo - I had a proof-of-concept once, hopefully getting it to a usable shape will be not that much more effort.

A propos, the videos from GoOOCon 2008... Friday was lost due to a technical problem :-( It is still not hopeless - a backup exists, unfortunately a bit malformed, so some more processing is necessary.

OOo startup speedups

Recently I was working on removal of some libraries from the OpenOffice.org startup procedure. They are not needed immediatiely during the startup, and can be loaded later when the user decides to use the functionality, or they are not needed at all any more. It saves disk access and linking time; I measured the win of the changes described below (on an AMD Geode based system, 'simulated cold start' using sync ; echo 3 > /proc/sys/vm/drop_caches), and it went down to 14.2s from 15.5s in KDE, to 11.5s from 12.7s in Gnome, and to 9.3s from 9.5s in WindowMaker (the win is smaller there because gnome-vfs wasn't used there even before the changes). I believe there is more time to save, and I'll try to find it of course ;-) Now what exactly was there:

gnome-vfs was initialized immediately during startup to avoid a deadlock. It has to be initialized in the thread as the Gtk+ itself; so moving the initialization to the main thread solved the problem, and gnome-vfs was removed from the startup. See issue 84137 for more.

Form controls in an empty document are initilized during startup because they are in 'design mode' (the user is able to create new form controls). This makes sense of course, but before the user creates the first form control, it is not necessary to load libfrm and all its dependencies - lots of users don't need form controls for their documents at all. See issue 84259 for more.

First start wizard is presented to the user during the first start of OOo to offer registration and migration of the settings from the previous version of OOo. Unfortunately, library that does this is loaded every time the OOo is started - just to check that there's nothing to do. See issue 84169.

localedata_es is a dependency of localedata_euro just because of one entry that can be easily moved to localedata_es itself. Very cheap win ;-), see issue 84206.

libstartup-notification was removed, because up-stream has never used it, and we (ooo-build) do not use any more either because of the external splash that we are trying to push up-stream for quite some time (another nice win, by the way). See issue 84179.

Another effort in this area is Caolan's great unifysound01 CWS which removes nas, sndfile and portaudio from the VCL dependencies.

One problem here is that we remove some stuff from the startup, and other creeps in. Michael had an idea to introduce a kind of OSL_ASSERT_NOT_BOOSTRAP() macro that would be added to the init functions of the components that for sure should not be in the startup procedure, and check for that in smoketest. I'll try to produce a patch for that shortly as well...