[Sugar-devel] Simplifying sugar-jhbuild

Bernie Innocenti bernie at codewiz.org
Thu May 21 14:28:07 EDT 2009


On 05/21/09 10:03, Tomeu Vizoso wrote:
>> 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?

I'm looking at the glucose-external.modules, and I see these modules
being checked out from the tip of the master branch:

 - squeak
 - hulahop
 - hippo-canvas


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

And besides, abiword 2.7.0 is not yet in F11 nor Jaunty.


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

Ok, but it's already packaged in all the distros we target, so why make
people spend precious time building it from source?


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

xulrunner now fails to build with gcc 4.4 (in F11) because of a tiny
error in an #elif directive.  Is there a way in jhbuild to apply patches
to sources?

xulrunner is also one of the worst compile time hog we have.  If we
could only build it on distros that require it, it would save a lot of
trouble to a lot of developers.

I'd vote for disabling it now and lazily wait to see if someone
complains before actually adding a workaround.


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

Ok, although this shouldn't impair them in any way.  We just move etoys
to a module that regular users don't have to build by default.


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

It's definitely not working, because we had to manually find out what
was missing along the way.  Do you have any idea where I should look?


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

OK.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/


More information about the Sugar-devel mailing list