+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).

Sugar-devel mailing list

Reply via email to