[Sugar-devel] Simplifying sugar-jhbuild

[Tomeu Vizoso]

On Wed, May 20, 2009 at 21:10, Bernie Innocenti <bernie at codewiz.org> wrote:
> 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.

We are supposed to be doing this already, which modules are not
following this rule?

> 2) Do not build C modules that is already available (and recent enough)
> in popular distros.  Specifically: abiword, matchbox, hippocanvas...

About abiword, we have been depending lately on modifications not
released on a tarball, but 2.7.0 was released recently and it should
contain all we need for now. If during 0.85 we need to hack further on
it, we may need to create unstable tarballs ourselves. Also, not all
distros are building it a way it can be used by Sugar, we should
check.

About hippo, we are the only users, so it can be considered as any
other Sugar module.

About xulrunner, we often want to test with the version that is going
to ship on the next distro releases, plus some distros still don't
package it in a way usable by Sugar (we should fix this).

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

I guess this makes sense, though would be good to hear people who hack
on eToys in Sugar.

> 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 :-)

We are supposed to be doing this already. If it's not working then we
should fix it.

> If there's consensus on implementing one or more of these points, I can
> provide patches (or just go on and commit them).

Totally, Sascha is the maintainer so coordinate with him.

Thanks,

Tomeu