Difference between revisions of "Platform Team/Guide/Sweets Usage"
< Platform Team | Guide
Jump to navigation
Jump to search
| Line 1: | Line 1: | ||
| − | This guide describes how to use [[Platform_Team/Doers_environment|Doers environment]] for developing core modules. | + | This guide describes how to use Sugar Labs' [[Platform_Team/Doers_environment|Doers environment]] for developing core modules. |
== Requirements == | == Requirements == | ||
| − | * Install PackageKit and PackageKit authentication agent from native packages. On Debian based systems, these packages are {{Code|packagekit}} and {{Code|packagekit-gnome}} (for Gnome Desktop Environment). | + | * Install PackageKit and PackageKit authentication agent from native packages. On Debian-based systems, these packages are {{Code|packagekit}} and {{Code|packagekit-gnome}} (for Gnome Desktop Environment). |
| − | * PackageKit authentication agent should be launched to let {{Code|sweets}} command install dependencies. Usually it is | + | * PackageKit authentication agent should be launched to let the {{Code|sweets}} command install dependencies. Usually it is started after being logged into a Doers environment session (it isn't for Sugar session). |
| − | * Download and launch [http://download.sugarlabs.org/packages/0sugar/sweets.sh self-extracted installer]. | + | * Download and launch our [http://download.sugarlabs.org/packages/0sugar/sweets.sh self-extracted installer]. |
| − | * Installer will add {{Code|~/.local/bin}} directory to the {{Code|PATH}}. So, | + | * Installer will add {{Code|~/.local/bin}} directory to the {{Code|PATH}}. So, re-login from an X session to take into account the new {{Code|PATH}}. |
== Clone the sources == | == Clone the sources == | ||
| Line 16: | Line 16: | ||
Where {{Code|--deep}} says {{Code|sweets}} process all dependencies. | Where {{Code|--deep}} says {{Code|sweets}} process all dependencies. | ||
| − | Each project will be placed | + | Each project will be placed into the default {{Code|~/sweets}} directory. These are regular sources clones with one exception, each project contains a [[Platform Team/Recipe Specification|sweets.recipe]] spec file. |
| − | Projects might be cloned in regular way | + | Projects might be cloned in the regular way; {{Code|sweets clone}} is just a convenient method since some of the projects are gitorious forks. |
== Launch sugar == | == Launch sugar == | ||
| Line 29: | Line 29: | ||
sweets sugar:emulator | sweets sugar:emulator | ||
| − | During the first launch, sources will be | + | During the first launch, sources will be built. To rebuild them at any time: |
sweets -ff make ''sweet'' | sweets -ff make ''sweet'' | ||
| Line 35: | Line 35: | ||
=== Run sweets from X session === | === Run sweets from X session === | ||
| − | Place sweets invocation | + | Place sweets invocation into your {{Code|~/.xsession}} file: |
PATH=$HOME/.local/bin:$PATH | PATH=$HOME/.local/bin:$PATH | ||
sweets sugar | sweets sugar | ||
| − | and create {{Code|/usr/share/xsessions/sweets.desktop}} desktop file: | + | and create a {{Code|/usr/share/xsessions/sweets.desktop}} desktop file: |
[Desktop Entry] | [Desktop Entry] | ||
| Line 51: | Line 51: | ||
== Develop == | == Develop == | ||
| − | Cloned projects will be built according to {{Code|[Build]}} section commands in recipe files. In general, for autotools based projects, there is no further need | + | Cloned projects will be built according to {{Code|[Build]}} section commands in recipe files. In general, for autotools-based projects, there is no further need for the {{Code|sweets}} command, just run {{Code|make install}} to build current sources and copy them to the directory that was specified by {{Code|sweets}} in the configure stage. |
| − | For glucose projects, there is no need even in calling {{Code|make}} command, python code will be reused from original place (see {{Code|binding}} options in recipe files), change the code and restart sugar. | + | For glucose projects, there is no need even in calling the {{Code|make}} command, python code will be reused from its original place (see {{Code|binding}} options in recipe files), change the code and restart sugar. |
For activities, follow regular activity developing procedure - clone them to {{Code|~/Activities}} directory and run from sugar shell. | For activities, follow regular activity developing procedure - clone them to {{Code|~/Activities}} directory and run from sugar shell. | ||
| Line 79: | Line 79: | ||
* Glucose needs to be patched, thus these are gitorious forks. | * Glucose needs to be patched, thus these are gitorious forks. | ||
| − | * Packages cannot be | + | * Packages cannot be built from sources without cloning. |
| − | * For now, {{Code|sweets}} knowns only about glucose dependencies to install them from native packages in Debian, Ubuntu, Fedora, Mandriva, openSUSE and Gentoo. | + | * For now, {{Code|sweets}} knowns only about glucose dependencies to install them from native packages in Debian, Ubuntu, Fedora, Mandriva, openSUSE, and Gentoo. |
* Activities can't reuse sweets benefits. | * Activities can't reuse sweets benefits. | ||
Revision as of 17:01, 13 January 2011
This guide describes how to use Sugar Labs' Doers environment for developing core modules.
Requirements
- Install PackageKit and PackageKit authentication agent from native packages. On Debian-based systems, these packages are
packagekitandpackagekit-gnome(for Gnome Desktop Environment). - PackageKit authentication agent should be launched to let the
sweetscommand install dependencies. Usually it is started after being logged into a Doers environment session (it isn't for Sugar session). - Download and launch our self-extracted installer.
- Installer will add
~/.local/bindirectory to thePATH. So, re-login from an X session to take into account the newPATH.
Clone the sources
To checkout sugar project sources:
sweets --deep clone sugar
Where --deep says sweets process all dependencies.
Each project will be placed into the default ~/sweets directory. These are regular sources clones with one exception, each project contains a sweets.recipe spec file.
Projects might be cloned in the regular way; sweets clone is just a convenient method since some of the projects are gitorious forks.
Launch sugar
To launch sugar session:
sweets sugar
or to run from Xephyr:
sweets sugar:emulator
During the first launch, sources will be built. To rebuild them at any time:
sweets -ff make sweet
Run sweets from X session
Place sweets invocation into your ~/.xsession file:
PATH=$HOME/.local/bin:$PATH sweets sugar
and create a /usr/share/xsessions/sweets.desktop desktop file:
[Desktop Entry] Encoding=UTF-8 Name=Sweets GenericName=Sweets Exec=/etc/X11/Xsession Type=Application
Develop
Cloned projects will be built according to [Build] section commands in recipe files. In general, for autotools-based projects, there is no further need for the sweets command, just run make install to build current sources and copy them to the directory that was specified by sweets in the configure stage.
For glucose projects, there is no need even in calling the make command, python code will be reused from its original place (see binding options in recipe files), change the code and restart sugar.
For activities, follow regular activity developing procedure - clone them to ~/Activities directory and run from sugar shell.
Upgrade
To use testing versions, enable "Help test new versions" checkbox on:
0launch -g
To upgrade sweets itself to the recent version:
sweets -R upgrade
Run sweets from sources
git clone git://git.sugarlabs.org/0sugar/sweets.git <install-path> echo 'PATH=~/.local/bin:$PATH' >> ~/.bashrc mkdir -p ~/.local/bin ln -fs <install-path>/0run ~/.local/bin/0run ln -fs 0run ~/.local/bin/sweets ln -fs 0run ~/.local/bin/0launch
Current limitations
- Glucose needs to be patched, thus these are gitorious forks.
- Packages cannot be built from sources without cloning.
- For now,
sweetsknowns only about glucose dependencies to install them from native packages in Debian, Ubuntu, Fedora, Mandriva, openSUSE, and Gentoo. - Activities can't reuse sweets benefits.