Difference between revisions of "Platform Team/Guide/Sweets Usage"
Line 34: | Line 34: | ||
sweets -ff make ''sweet'' | sweets -ff make ''sweet'' | ||
+ | |||
+ | To see build output, use {{Code|-v}} command line argument (adding more {{Code|-v}} arguments will increase verbose level). | ||
=== Run sweets from X session === | === Run sweets from X session === |
Revision as of 13:17, 4 February 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
packagekit
andpackagekit-gnome
(for Gnome Desktop Environment). For Fedora,PackageKit
andgnome-packagekit
. - PackageKit authentication agent should be launched to let the
sweets
command install dependencies. Usually it is started after being logged into a Desktop Environment session (it isn't for Sugar session). - Download and launch our self-extracted installer. Note, sweets is not intended to be installed from
root
user, use your current system user all time. - Installer will add
~/.local/bin
directory 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
To see build output, use -v
command line argument (adding more -v
arguments will increase verbose level).
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
Development workflow with sweets
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 sweets.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 <full-install-path>/0run ~/.local/bin/0run ln -fs 0run ~/.local/bin/sweets ln -fs 0run ~/.local/bin/0launch cd <install-path> git submodule init git submodule update
Current limitations
- Glucose needs to be patched, thus these are gitorious forks.
- Packages cannot be built from sources without cloning.
- For now,
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.
Feedback
- Submit your bug report.
- Ask your question on IRC channels, #sugar (not logged) or #sugar-newbies (logged).