On Sun, May 24, 2009 at 13:31, Bastien <bastiengue...@googlemail.com> wrote:
> +1 on the overall.
> Building Sugar from source should be as easy as:
> ,----
> | ~$ git://git.sugarlabs.org/sugar-core/mainline.git
> | ~$ ./configure
> | ~$ make
> | ~$ sudo make install
> `----

Well, that works for the sugar shell provided you have all the
dependencies installed. The point of jhbuild is precisely to get you
an environment where all the dependencies of the software you are
interested in are installed without breaking your regular desktop.

Please note that we don't need to use sudo as all dependencies are
installed in a user-writable directory.



> (Sidenote: I guess it's a gitorious thingy, but mainline.git is a pretty
> stupid name for a git repo. It forces the user to create folders by hand
> when pulling several projects.  Why not sugar-core.git?)
> I would also advocate having sugar-jhbuild reduced to sugar-core, where
> the only activity is the Journal.  Other activities should be installed
> separately, either one by one or by bundle.
> Bernie Innocenti <ber...@codewiz.org> writes:
>> Today I've kick-started a newbie on building Sugar to fix a small bug
>> and submit his first patch.
>> It was just painful.  jhbuild has plenty of rough corners and we could
>> easily make things easier with a few changes:
>> 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.
>> 2) Do not build C modules that is already available (and recent enough)
>> in popular distros.  Specifically: abiword, matchbox, hippocanvas...
>> 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.
>> 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 :-)
>> If there's consensus on implementing one or more of these points, I can
>> provide patches (or just go on and commit them).
> --
>  Bastien
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
Sugar-devel mailing list

Reply via email to