[Sugar-devel] jhbuild improvement?

[Aleksey Lim]

On Thu, Sep 29, 2011 at 06:21:53PM -0400, Bernie Innocenti wrote:
> 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:

Firstly, the difference I pointed is that a flexibility of using
Sweets in comparing jhbuild to code sugar, i.e., jhbuild is a black
box supported in a separate project that covers the full sugar related
infra at once. At the same time Sweets is a PMS, and sugar/ here is a "package"
in this pms. You clone the sugar sources (not ask jhbuild to clone sugar
somewhere). Code it. And run it (right from the place you cloned it
before).

The second point, Sweets is a PMS. It is not an initiative to replace
jbuild (but for me it is more useful than jhbuild), but rather to have
on-top-of-distro PMS that support Sugar way for development, i.e.,
learning via doing(coding), share results of experiments (because it is
cirtical for learning process), etc.

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

~/.local seems to be a common place for such stuff, If ~/bin is also
being used in several distros (I don't have it in mine), then it will be
a good candidate to replace ~/.local. I saw it only on Debian/Ubuntu.

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

PK is a critical component in Sweets. It is pretty simple, if Sugar
ecosystem is not about "only-one-distro(put here your favorite)", then
we either need to reuse existed PK or reinvent it. There is a good
progress in pushing PK to several distros, I even have it on Gentoo,
on recent Distros it just works.

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

Thats not a fail of Sweets but a fail of particular sweet (ie package).
And there is a reasong for that: for now, there is no GUI to run
activities from Sweets (but on low level, it is possible), thus sugar
sweet needs to include such deps (the good point in comparing w/
jhbuild, is that if you don't like it, you need to change sugar sources,
not jhbuild's - edit sugar/sweets.recipe).

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

Deps issue was already covered in prev. paragraph. The building from
sources, thats another not trivial issue. And Sweets is designed to
solve it using another tool - OBS. Here you got building from sources
for all deps because there are no binaries built exactly for you
distro/arch, e.g., for now there are only blobs for Fedora-14 and
Ubuntu-10.10: http://download.sugarlabs.org/sweets/sdk/csound-python/.
These binaries were built on OBS in automatic manner - dev only uploaded
sources to obs.sugarlabs.org.

> leading to fragility and
> complexity for the user.

There is no magic (and here problem in particular sweets, not in Sweets),
the entirely Sweet initiative is not about "Click the one button" it is
about having a tool (that does, in my mind, its work better than jhbuild
for build sugar, though Sweets is more that building only sugar).

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

I already mentioned this issue, in my env I have modified
sugar/sweets.recipe that have all fructose deps commented out.

> 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
like in Sweets workflow

>   sudo ./install-deps.sh
>   ./autogen.sh
>   make
>   make install
>   ./install/bin/sugar
like in Sweets workflow, take a look into sugar/sweets.recipe

> 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.
ie, all these established patterns are included into Sweets. But Sweets
have solutions for non-trivial issues mixed in (yes, w/ pkg-config you
can check if you have or not some dep, but w/ Sweets you also (in
addition) have a chance to install it).

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

The entirely idea behind Sweets is covering both use cases (and doing it
reasonably well). If Sweets "packages", ie, sweets, are in good quality,
the only steps not skilled people need to do to run sugar are:

* Install PackageKit
* Install Sweets
* Run sugar: sweets sdk/sugar

-- 
Aleksey