by Greg DeKoenigsberg
One Laptop Per Child comes closer to being a reality every day — and every day, more people are looking for ways to get involved with the OLPC project. It will still be quite a while before the XO systems are available for broad distribution, but people can see for themselves what the XO is all about by downloading Sugar, the core of the OLPC Human Interface.
Sugar, for those who aren’t familiar with it, is very different from the desktop environment to which Linux users have become accustomed. The XO was conceived as a tool to allow kids to learn interactively, and Sugar has been designed for that purpose. The first thing that a child sees, therefore, is not a hard disk or a trash can — it’s the other kids in the “neighborhood”. Sugar developers are encouraged to write activities with collaborative elements that are enabled by default. The Human Interface Guidelines discuss the Sugar philosophy in some detail, but really, there’s no substitute for experiencing Sugar directly.
The best way to experience Sugar, though, is to build it from scratch — especially if you want to take the next step and develop activities for use with Sugar. Fortunately, building Sugar is getting easier with each milestone. Here are some pointers to get you started.
The first thing to understand about Sugar is that it’s based on the future Fedora 7 — which means that unless you’re one of the hardy souls who runs Fedora rawhide, you’re not going to be able to build Sugar on top of whatever Linux distribution you’re running currently without making a few tweaks. That’s part of being a developer: dealing with ever-changing environments.
Good tools help, though. The problem of managing lots of differently built components is a problem that GNOME developers face every day — which is why the Sugar developers have borrowed James Henstridge’s excellent jhbuild from the GNOME project and customized it for use with Sugar. Whether you’re running Fedora, Ubuntu, Debian or Mandriva, you can easily run sugar-jhbuild.
Really, sugar-jhbuild isn’t that complicated; it’s essentially a set of glue scripts that download source code from various repository types, build all that code, and put the resulting binaries into a local directory. The downside of the jhbuild approach is that you’re essentially building a miniature distribution from scratch — kind of like a mini-Gentoo — and that requires both disk space and time. The upside, though, is that the maintainers of the project do all the work of configuring sugar-jhbuild up front. All you have to do is run the scripts, maybe do a little troubleshooting, and be patient. Oh, and make sure that you have git, CVS and subversion installed.
Downloading the Sugar Builder
git-clone git://dev.laptop.org/sugar-jhbuild `date +%F`-SUGAR
cd `date +%F`-SUGAR
This is the first step: go get sugar-jhbuild by cloning its git repository. The sugar directory thus created (in the case of the above command, tagged with creation date) will be the home of your new Sugar environment. Source and binaries both will end up in this directory, so make sure you’ve got plenty of disk space allocated for it. The last version I built took 3 Gigabytes to download and build, so be prepared.
Bootstrapping the Sugar Builder
yum -y update
yum groupinstall "Development Tools"
yum groupinstall "X Software Development"
For Fedora Core 6 users, the preceding section is for you. Run the preceding
yum commands as root; these will ensure that you’ve got all of the Fedora development packages required to bootstrap sugar-jhbuild. If you use another distro, your mileage will vary; run
./sugar-jhbuild sanitycheck to figure out what you need to install to run sugar-jhbuild for your particular distribution.
Downloading the Sugar Source
./sugar-jhbuild update meta-sugar-base
In this step, you will go get all of the source files you’ll need to build Sugar. The first command retrieves the source files for all of the dependencies required to build Sugar; the second command retrieves the source files for Sugar itself.
Note that it’s entirely possible to run the build scripts without explicitly downloading all of the source files first. The build scripts always update the source files anyway as part of the build process. So why should you run these updates first?
Because getting all the sources can take a while, and this can be the most frustrating part of the process. You’ll be pulling large chunks of code from a whole bunch of different sites. Some of these sites may be up; some of them may be down; some of them may be really, really slow. Maybe subversion will time out on you, and you’ll have to kill sugar-jhbuild, kill the subversion process, blow away that part of the source tree and start again. (Like, for instance:
rm -rf source/libxml2; ./sugar-jhbuild update meta-sugar-base, which I did a half-dozen times.)
Once the source files have all been retrieved, though, the build steps can run largely unattended. Even if some of your source becomes outdated, it will be much easier to download a small source diff than an entire source tree.
Building the Sugar Binaries
./sugar-jhbuild build meta-sugar-base
Now it’s time to build Sugar’s direct dependencies: autoconf, python, pygtk, avahi, mozilla, and many others. These are all covered under the meta-sugar-base dependency established in sugar-jhbuild.
“But wait,” you say, “I already have all of these things installed on my system,” and so you do. But you’ve almost certainly got versions that Sugar isn’t interested in. For instance, I’m running Fedora Core 6, which has Python 2.4.4 running by default — but Sugar needs Python 2.5. Therefore, sugar-jhbuild will build Python 2.5, and other specific application versions required by Sugar, and will install these versions into the bin/ and/or lib/ directories in your Sugar directory.
So kick off that build. You might want to go to dinner now. Or maybe to bed. It’ll finish at some point, but don’t wait up. Mozilla alone can take several hours. But be patient; it’s worth the wait.
At long last, you’re finally ready to build Sugar and all of its activities.
This is actually the quickest part of the build. It’s also the part most likely to break, since the components here are most likely to be in flux at any given time. If your build breaks here, though, you’ve got immediate recourse; the friendly folks on the Sugar mailing list will be happy to help, especially if you’ve found a real bug. Which, at this early stage in Sugar’s life, could be quite likely.
You’ve built it; now it’s time to run it. To run Sugar, use the
sugar-jhbuild run command. This will set all of the necessary environment variables for Sugar. For instance, it will tell Sugar to use the custom-installed Python 2.5 instead of the likely system default of Python 2.4.
It may not be clear to you how Sugar works. That’s okay; it’s a very different environment than most Linux geeks are used to. If you need some hints, be sure to check out the release notes to understand the nuances of the Sugar interface; even though the notes were written for the actual XO itself, they apply to the Sugar software as well.
A few quick commands to get you started:
- Alt-F makes the frame come and go.
- Alt-C quits an activity.
- Alt-0 brings up the developers console.
- Alt-Q quits Sugar.
Again, if you find bugs, pop on to the Sugar mailing list and say hello. The growing Sugar community will be delighted to help you.
Next up: writing Sugar activities
All done for now; with patience and a bit of luck, your very own instance of Sugar should be installed and running. Have fun playing with Sugar and all of its activities.
Next time, we’ll focus on writing our first activity for the XO.