[Sugar-devel] The ARM is near

[Lucian Branescu]

I suggested pre-parsed code mostly to get rid of dependency on headers
and other source packages; a bit like a JIT that always compiles and
caches everything. LLVM IR in particular is just a high lever
assembler, so it could be distributed without any dependencies (even
on build tools).

There's also the small advantage that developers get to not only
parse, but optimise the code beforehand, so code generation on a
production machine should be rather fast. This whole idea may be too
complex for its own good, though.


As for more conventional compilation strategies, I think it would be
best if Sugar itself to compiled all the code from the bundle on
installation, instead of leaving it to the activity. Then, the
activity developer simply includes all the C source and headers, much
the way one would include python source.

2009/8/29 Benjamin M. Schwartz <bmschwar at fas.harvard.edu>:
> 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
>
>
>