[Sugar-devel] Simplifying sugar-jhbuild

[Tomeu Vizoso]

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

As with any other sugar module, people want to run the latest code
because it will contain bugfixes, etc. I see hulahop in the same way.

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

Yeah, we may be doing it still in some modules.

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

No need to do that for all users, we can do it distro by distro. I
think that each distro in jhbuild should have its maintainer, as
Sascha cannot run all of them.

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

Fine with me.

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

Grep for depscheck, though it's an expensive process and may not be
fun to have it run at every jhbuild invocation.

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

Also, maybe what we need is better documentation rather than big
changes that bring new problems?

Regards,

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