5,705
edits
Changes
Jump to navigation
Jump to search
Line 214:
Line 214: + + + + + + + + + + + + + + + + + + + + + + + + +
Platform Team/Guide/Sweets Packaging (view source)
Revision as of 15:15, 6 December 2011
, 15:15, 6 December 2011→Development with Sweets
and see its {{Code|sweets.recipe}} files.
and see its {{Code|sweets.recipe}} files.
=== Developing activities ===
The regular way for development related routines regarding activity sources is runing {{Code|setup.py}} script located in the root activity directory. With Sweets, all this routines might be be done suing {{Code|sweets}} command. The reasons are:
* The downside of using Sweets is that running {{Code|setup.py}} requires being in the Sugar session (to have all libraries that {{Code|setup.py}} injected);
* Sweets is designed to support multiple software versions at the same time, it might be not useful to loging to every Sugar session for creating, e.g., source tarballs; In other words, having standalone utility makes more sense;
* {{Code|sweets}} command already contains development related functionality, it is useful to keep all development related functions in one utility.
Sweets support the following {{Code|setup.pu}}'s commands:
* {{Code|build}}, build generated files
* {{Code|dist_xo}}, create a .xo with activity sources
* {{Code|dist_source}}, create activity sources tarball
* {{Code|genpot}}, generate the gettext pot file
And don't support the following:
* {{Code|dev}}, seems to be needlessly exaggerated, function creates symbolic link in {{Code|~/Activities}} directory to activity sources, the same might be done using {{Code|ln -s}} command to avoid having derived functionality;
* {{Code|fix_manifest}}, function create {{Code|MANIFEST}} file, not having this file is not a fail and Sweets is designed to have include/exclude rules in recipe files;
* {{Code|install}}, function installs activity to the root system, Sweets avoid, by design, any global changes during the regular behaviour.
As regular {{Code|sweets}'s commands, these command need to be executed being in activity directory (in any of its sub-directories, not only in the root), or path to activity sources might be specified after command name:
sweets build [PATH]
== Good practices ==
== Good practices ==