[Sugar-devel] Bundles with binary requirements (Was: The ARM is near)

[Gary C Martin]

Hi Benjamin,

On 28 Aug 2009, at 03:58, Benjamin M. Schwartz wrote:

> Bobby Powers wrote:
>> I think having something like:
>>
>> example.activity
>> |-arch/
>> |-arch/x86/
>> |-arch/x86/bin/
>> |-arch/x86/lib/
>> |-arch/armel/
>> ...
>>
>> could work.  Sugar could set an environmental variable ARCH to the
>> relevant value, and we could have a reference activity_startup.sh
>> which adds the correct lib path to LD_LIBRARY_PATH and launches the
>> appropriate executable (or maybe a flag in activty.info which has
>> sugar do this).  This is still somewhat kludgy, but I'm not sure of a
>> better way.
>
> Which solution we should choose is a technical discussion that  
> deserves
> its own thread.  I'm personally not enthusiastic about the "fat  
> packages"
> approach, in which binaries for many architectures are included in  
> one .xo
> bundle, because:

What would be your recommendation?  As a long time Mac user (and  
developer) I was/am all for "fat packages" (universal binaries), and  
we certainly don't have the ability to compile binaries on demand for  
the significant portion of target sugar HW. Activity bundles are a  
major plus, from where I'm standing, vs. the traditional ./configure,  
make install, and dependancy requirements.

With my activity author hat on, I've gone out of my way to avoid the  
hell of binary blobs, it breaks the whole idea of providing code in  
Python source for others to easily edit, modify, learn from. But I  
understand (having adopted maintenance of some old projects) that this  
has not always been possible for authors (though it woul would always  
be my goal when writing code).

Regards,
--Gary