[Sugar-devel] Introducing sugar-build

[Bernie Innocenti]

On Thu, 2012-06-14 at 12:06 +0200, Daniel Narvaez wrote:
> * I think these tools are used by few people because they don't work
> well. I know despite having a lot of experience with GNOME and linux
> builds I was highly frustrated by sugar-jhbuild complexity and
> unreliability. I'm sure a lot of people have been in that situation
> and gave up. This is not to pick on sugar-jhbuild, as I said in
> rationale it's a very difficult issue to solve. Mine is another
> try.and I agree with who said competition is good here.

This is also my experience, and I saw several developers at deployments
who were struggling to build Sugar from source in jhbuild.

I used to believe jhbuild could be improved in incremental steps, by
shaving off dependencies and removing complexity here and there, but
after several years it's still very fragile.

The hardest issue seems to be finding consensus among the developers on
one of the solutions. My preference would be towards merging all the
glucose modules into a single repository that could be built with the
familiar sequence of commands "configure && make && make install".

This is basically what sugar-core [1] already did 2 years ago. It was
created by Marco Pesenti Gritti based upon an earlier proposal of
Michael Stone [2].

Both of them had had enough of fighting jhbuild and wanted something
simple and clean by merging the repositories. Michael's proposal was
more radical because it also replaced the autoconf build system with a
hand-made configure script and a hand-made Makefile, both very short.
I'm not sure I'd go that far, but it was a tempting idea.


[1] http://sugar.marcopg.org/intro.html#build-from-source-code
[2] http://dev.laptop.org/git/users/mstone/sugar/


> * Maintenance of these tools has an high cost but losing talented
> contributors because they are unable to get the thing to build is a
> much much higher one. Also, many of the design choices in sugar-build
> intends to reduce maintenance cost (which I think in turn will favor
> reliability).

I couldn't agree more on your motives, but I think that jhbuild simply
deserves to die. Wrapping it with something easier to use can be a
temporary solution, but it can't eliminate all the underlaying
complexity of repeated network operations to fetch code from disparate
repositories.

-- 
Bernie Innocenti
Sugar Labs Infrastructure Team
http://wiki.sugarlabs.org/go/Infrastructure_Team