Posts Tagged ‘vmware’

Start of coding

Monday, May 26th, 2008

Well today is the official start of coding for Google Summer of Code, but for me I won’t be able to start coding for another couple of days; I have an exam tomorrow and a programming assignment due Wednesday so I can’t really begin work till then.

In the meantime though I’ve been getting Gnome SVN compiled, using the git-svn support in jhbuild, which has meant I’ve committed a few improvements to the git-svn support to speed up the process; namely I’ve improved the svn:externals support by parsing the unhandled.log that git generates. I’d still like to improve the support further, adding support for git-svn repos with a full complement of branches being one(although doing this properly will require additional information about how the repository is laid out), but it’s usable in its current form for now. I’m also currently using icecream to speed up my compiles, currently running on my desktop and laptop, but I’d like to setup a minimal VMWare image containing just the icecream client and minimal dev environment so that I can run this on the other machines that are at my parents, when I return there after finishing uni. Does anyone know of any existing images that are available or will I have to roll my own? A quick glance at the VMWare virtual appliances shows no results for this kind of appliance so it looks like I’ll have to roll my own.

I’ve also been looking at the general code structure for the background drawing code and generally getting a feel for what needs to be done in this regard. In particular, I need to design a structure for the GConf keys that works with backwards compatibility: the background configuration is currently stored in the /desktop/gnome/background GConf key. The two current solutions I’m thinking of are adding a subdirectory for each workspace configuration /desktop/gnome/background/Workspace1 or storing it as /desktop/gnome/Workspace1/background. I’m currently leaning towards the second solution as it means that the scheme can be extended to support per workspace properties for other keys such as /desktop/gnome/interface for setting per workspace themes/fonts. The idea would then be that if a workspace specific key doesn’t exist in /desktop/gnome/*WorkspaceName* then it would fall back to the key in /desktop/gnome/. This provides the backwards compatibility aspect with older gnome installations. The challenge with this however comes when writing the configuration gui – when do you update the default background key?

Tags: , , , , , ,
Posted in Google Summer of Code | 4 Comments »

JHbuild

Sunday, May 4th, 2008

I tried to get a build of gnome done on my computer using the jhbuild tool. I like the way it uses libnotify to inform you when there is a build error. It’s meant that I can leave it compiling in the background whilst doing work on my Masters project and only pay attention when there are errors.

I got stuck compiling pixman with the same error as found here. Unfortunately the fix provided in this case didn’t work for me. I tried both using jhbuild build -a and adding the appropriate PKG_CONFIG_PATH lines to my .jhbuildrc file without success.

Turns out the error was due to one of the tests in pixman was trying to link against gtk which had yet to be built by jhbuild and so was trying to pull in the system version of gtk which linked against the system version of glib, which was listed first on the command line and hence took priority, resulting in the error.

Now I’m not the only one to have this problem: http://bugzilla.gnome.org/show_bug.cgi?id=344358. The reason for the problem is when the system already has the dev packages installed for the system’s installation of Gnome, in my case this is because I am running Gentoo. The solution given on #gnome-love on irc.gnome.org was to remove all *.la files from my system. This isn’t really an acceptable solution for a distribution that is compiled from source – I need the libtool library files to update my system!

Making sure a build system compiles on a fresh checkout for a new user is a problem that I came across when maintaining the build system for a fluid dynamics software suite I worked on at BAE Systems. It’s all too easy to write a build system that relies on source already being installed, and miss the small things that a new user will be stumped by, even if it is only a 1 minute fix to you. I wouldn’t be surprised if I start hacking at jhbuild in the near future as these things do niggle me, especially if I can think of a way to fix them!

Despite all this I’ve managed to, through a mixture of running jhbuild with the -a flag, manually running configure, and modifying my .jhbuildrc file to set environment variables and build options, to get most of the latest dev version of gnome compiled now (at least the parts that I need to work on). Next step is to point the jhbuild moduleset to my git repositories (I’ll post a url once I begin development), although to avoid future pain I may resort to setting up a VMware image with Fedora or Ubuntu on it to use as a sandbox environment for testing.

Tags: , , ,
Posted in Google Summer of Code | No Comments »