Construindo o XO: Introduzindo Sugar: Difference between revisions
(Versão inicial) |
No edit summary |
||
Line 1: | Line 1: | ||
Este página contém a tradução do artigo [http://www.redhatmagazine.com/2007/02/23/building-the-xo-introducing-sugar/ Building the XO: Introducing Sugar], de [http://www.redhatmagazine.com/author/gregdek/ Greg DeKoenigsberg], publicado na Red Hat Magazine em 23 de fevereiro de 2007. Atualmente está em andamento. |
Este página contém a tradução do artigo [http://www.redhatmagazine.com/2007/02/23/building-the-xo-introducing-sugar/ Building the XO: Introducing Sugar], de [http://www.redhatmagazine.com/author/gregdek/ Greg DeKoenigsberg], publicado na Red Hat Magazine em 23 de fevereiro de 2007. Atualmente esta tradução está em andamento. |
||
A cada dia o Um Laptop Por Criança aproxima-se da realidade - e a cada dia, mais pessoas procuram maneiras de se envolver com o projeto OLPC. Ainda demorará certo tempo antes que os sistemas XO estejam disponíveis para ampla distribuição, mas as pessoas podem ver por elas mesmas sobre tudo o que o XO é baixando o Sugar, o núcleo da Interface Humana do OLPC. |
A cada dia o Um Laptop Por Criança aproxima-se da realidade - e a cada dia, mais pessoas procuram maneiras de se envolver com o projeto OLPC. Ainda demorará certo tempo antes que os sistemas XO estejam disponíveis para ampla distribuição, mas as pessoas podem ver por elas mesmas sobre tudo o que o XO é baixando o Sugar, o núcleo da Interface Humana do OLPC. |
||
Line 6: | Line 6: | ||
Existem algumas maneiras de testar o Sugar. Existem versões Live CD, e também imagens binárias que podem ser executadas em modo de emulação com um ambiente de emulação como o qemu. |
Existem algumas maneiras de testar o Sugar. Existem versões Live CD, e também imagens binárias que podem ser executadas em modo de emulação com um ambiente de emulação como o qemu. |
||
A melhor maneira de experimentar o Sugar, no entanto, é construí-lo a partir do código fonte - especialmente se você deseja prosseguir para o próximo passo e desenvolver atividades a serem usadas com o Sugar. Felizmente, construir o Sugar está se tornando mais fácil a cada nova versão. Aqui estão algumas direções a serem seguidas para iniciar. |
|||
Informações básicas |
|||
A primeira coisa a entender sobre o Sugar é que ele é baseado no futuro Fedora 7 - o que significa que não será possível construir o Sugar sobre qualquer distribuição Linux que você esteja rodando sem fazer alguns ajustes. Isto é parte de ser um desenvolvedor: lidar com ambientes em permanente mudança. |
|||
Boas ferramentas ajudam, no entanto. O problema de gerenciar vários componentes construídos de formas diferentes é um problema que os desenvolvedores do GNOME enfrentam todos os dias - e é por isso que os desenvolvedores do Sugar tomaram emprestado o excelente jhbuild criado por James Henstridge do projeto GNOME e adaptaram para uso com o Sugar. |
|||
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 |
|||
./sugar-jhbuild update |
|||
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. |
|||
./sugar-jhbuild build |
|||
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. |
|||
Running Sugar |
|||
./sugar-jhbuild run |
|||
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. |
Revision as of 16:25, 17 April 2007
Este página contém a tradução do artigo Building the XO: Introducing Sugar, de Greg DeKoenigsberg, publicado na Red Hat Magazine em 23 de fevereiro de 2007. Atualmente esta tradução está em andamento.
A cada dia o Um Laptop Por Criança aproxima-se da realidade - e a cada dia, mais pessoas procuram maneiras de se envolver com o projeto OLPC. Ainda demorará certo tempo antes que os sistemas XO estejam disponíveis para ampla distribuição, mas as pessoas podem ver por elas mesmas sobre tudo o que o XO é baixando o Sugar, o núcleo da Interface Humana do OLPC.
O Sugar, para aqueles que não são familiares com ele, é bastante diferente do ambiente desktop ao qual usuários Linux se acostumaram. O XO foi concebido como uma ferramenta para permitir a crianças aprender interativamente, e o Sugar foi concebido com esse objetivo. A primeira coisa que uma criança vê, consequentemente, não é um disco rígido ou uma lata de lixo - é as outras crianças da "vizinhança". Desenvolvedores do Sugar são encorajados a escrever atividades com os elementos colaborativos que são habilitados por padrão. As Linhas-guia da Interface Humana discutem a filosofia do Sugar em detalhes, mas na realidade não há substituto para a experiência de usar o Sugar diretamente.
Existem algumas maneiras de testar o Sugar. Existem versões Live CD, e também imagens binárias que podem ser executadas em modo de emulação com um ambiente de emulação como o qemu.
A melhor maneira de experimentar o Sugar, no entanto, é construí-lo a partir do código fonte - especialmente se você deseja prosseguir para o próximo passo e desenvolver atividades a serem usadas com o Sugar. Felizmente, construir o Sugar está se tornando mais fácil a cada nova versão. Aqui estão algumas direções a serem seguidas para iniciar.
Informações básicas
A primeira coisa a entender sobre o Sugar é que ele é baseado no futuro Fedora 7 - o que significa que não será possível construir o Sugar sobre qualquer distribuição Linux que você esteja rodando sem fazer alguns ajustes. Isto é parte de ser um desenvolvedor: lidar com ambientes em permanente mudança.
Boas ferramentas ajudam, no entanto. O problema de gerenciar vários componentes construídos de formas diferentes é um problema que os desenvolvedores do GNOME enfrentam todos os dias - e é por isso que os desenvolvedores do Sugar tomaram emprestado o excelente jhbuild criado por James Henstridge do projeto GNOME e adaptaram para uso com o Sugar.
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 ./sugar-jhbuild update
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.
./sugar-jhbuild build
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.
Running Sugar
./sugar-jhbuild run
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.