[Sugar-devel] jhbuild improvement?

Bernie Innocenti bernie at sugarlabs.org
Thu Sep 29 18:21:53 EDT 2011


On Thu, 2011-09-29 at 12:07 +0000, Aleksey Lim wrote:
> On Wed, Sep 28, 2011 at 10:35:55PM -0400, Bernie Innocenti wrote:
> > I was reading in the Gnome 3.2 release notes:
> > 
> > ------------------------------------------------------------------------
> > GNOME's build tool JHBuild does not build a module anymore if the
> > version installed on your system is recent enough. This is controlled by
> > the configuration option partial_build and it is enabled by default. The
> > command jhbuild sysdeps lists which system modules have been found as
> > well as the modules that are going to be build.
> > 
> > If you start to build GNOME from scratch with a recent distribution,
> > this can easily drop 50 modules from the list of modules to compile.
> > ------------------------------------------------------------------------
> > 
> > This feature could potentially reduce the complexity for setting up a
> > new development environment. What do you think?
> 
> To reduce "jhbuild" complexity, maybe. But not sure if jhbuild will be
> more useful than:
> 
> * install PackageKit
> * install Sweets: wget http://download.sugarlabs.org/sweets/sweets/installer.sh && sh installer.sh
> * clone sources (that have sweets.recipe) you need to code: git clone git://git.sugarlabs.org/sdk/sugar.git sugar/
> * make your changes in sugar/ code
> * launch your changes: sweets sugar/:emulator

Ok, I tried this out. Here are a few observations:

1. The sweet binary was symlinked to ~/.local/bin/sweets.
Why not ~/bin, which would be already in the path for most distros?

2. On my Ubuntu Lucid desktop, PackageKit is a little too dumb: it bails
out because of a minor dependency problem on my system. I solved it by
running apt-get manually, which offered me to downgrade a couple of
packages. If it works better on more recent distros, we don't have to
worry too much about this.

3. Sweets tried to build csound-python from sources even though there's
a distro package for it. Moreover, the build fails on x86_64 due to a
missing -fPIC. Installing the package manually with apt fixed the issue.

4. Same thing for pybox2d, which isn't even available in Lucid :-(

5. Why are things like csound and box2d specified as dependencies of the
sugar package? If I'm doing development on Sugar core, I don't care
whether TamTam and Physics work.

In the end, my newbie experience with sweets is not much better than
jhbuild. Both these build systems seem too aggressive in pulling in
dependencies and building things from source, leading to fragility and
complexity for the user.

It doesn't have to be so complex. I think we should streamline things
for the use-case that matters to new developers: build and run Sugar and
nothing else. No etoys, no Browse, no weird python bindings -- Just
Sugar.

With their sugar-core proposal, mstone & marcopg got really close to the
ideal build environment for developers:

  git clone git://git.sugarlabs.org/sugar-core/mainline.git sugar-core
  sudo ./install-deps.sh
  ./autogen.sh
  make
  make install
  ./install/bin/sugar

It uses well established patterns that every Linux user is already
familiar with. It doesn't require learning an entirely new cross-distro
dependency system.

Packagers and advanced developers with sophisticated requirements can
integrate sugar-core into a more comprehensive build system based on
sweets and/or jhbuild.

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



More information about the Sugar-devel mailing list