+1 on the overall. Building Sugar from source should be as easy as:
,---- | ~$ git://git.sugarlabs.org/sugar-core/mainline.git | ~$ ./configure | ~$ make | ~$ sudo make install `---- (Sidenote: I guess it's a gitorious thingy, but mainline.git is a pretty stupid name for a git repo. It forces the user to create folders by hand when pulling several projects. Why not sugar-core.git?) I would also advocate having sugar-jhbuild reduced to sugar-core, where the only activity is the Journal. Other activities should be installed separately, either one by one or by bundle. Bernie Innocenti <ber...@codewiz.org> writes: > Today I've kick-started a newbie on building Sugar to fix a small bug > and submit his first patch. > > It was just painful. jhbuild has plenty of rough corners and we could > easily make things easier with a few changes: > > 1) Stop checking out random unstable versions of external projects. > They break very often, and we cannot fix them. Let's instead upgrade > manually every once in a while after some testing. > > 2) Do not build C modules that is already available (and recent enough) > in popular distros. Specifically: abiword, matchbox, hippocanvas... > > 3) Let's move etoys away from the base set of components: the repository > is often offline, building it breaks very often, and it takes a lot of > time. You don't need it in order to test Sugar, the same way you don't > need TamTam and TurtleArt. > > 4) We could check for prerequisites before starting the build. Some > configure scripts are stupid enough to fail tests silently and proceed > anyway using "no" as a command name in make :-) > > If there's consensus on implementing one or more of these points, I can > provide patches (or just go on and commit them). -- Bastien _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel