[Sugar-devel] The ARM is near

[Benjamin M. Schwartz]

Lucian Branescu wrote:
> This is a bit of a stretch, but would it be possible to distribute
> GIMPLE or LLVM IR and finish the compilation on installation?
> Installing would take longer, but it should work on any architecture
> the code can compile to.

Currently, Sugar has a number of blessed interpreters: CPython,
Spidermonkey, Squeak, bash, and arguably sed and awk.  I think it would be
easy to add a C compiler to the list.  (I also think skipping the C parser
stage by shipping an intermediate representation is a premature optimization.)

Providing a C compiler would enable the use of C source code in activity
bundles.  Activities would be responsible for running a script to initiate
compilation, and for caching the binaries in /data to avoid recompiling on
every launch.  We can provide a standard script for this (like
sugar-launch), for the convenience of activity authors.  It would be useful.

It's more difficult to say that simply adding a compiler solves the
problem of dependencies on existing binary packages.  For example, many
packages require build systems like ant, autotools, CMake, GNU make,
imake, or SCons.  Unless we also provide all of these build systems,
Activities will have to compile the build systems for their dependencies,
before they can build their dependencies.  It may be acceptable to bless
one or more of these build systems, to partially alleviate this problem.

Activity bundles can test for the presence of installed applications
easily enough, to avoid unnecessary compilation.    They may also attempt
to download arch-appropriate binary packages over the internet, and
compile the included source only if such binaries cannot be found.  (I am
specifically referring to binary packages constructed to permit
unprivileged installation and use, such Gentoo Prefix binpackages or
0install bundles.)  We could provide a service to allow Activities to
search for binary packages already downloaded, and inform them of
preferred package servers.

Activities could also pause and ask the user to install certain packages
through the system package manager, falling back to compilation only if
the user declines (or fails).  It may be possible to use PackageKit and
PolicyKit to streamline this process, but it does not seem to be strictly
necessary.

A remaining serious issue is headers.  I don't yet totally understand this
problem, but many applications can only be compiled in the presence of
appropriate library headers, and in many distributions the appropriate
headers are not present by default (they are in -devel packages).  It may
be necessary for Sugar to depend on all these -devel packages so that
Activities can compile and link correctly.  This is a significant cost in
disk space.

--Ben


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090829/a0cf6a4e/attachment.pgp