[Vm-dev] VM packaging for Cog transition

[Bert Freudenberg]

On 08.11.2010, at 04:55, David T. Lewis wrote:

> On Sun, Nov 07, 2010 at 07:29:56PM -0800, Andreas Raab wrote:
>> 
>> On 11/7/2010 12:27 PM, David T. Lewis wrote:
>>> The above is just my $.02 to get the discussion started. What do others 
>>> think?
>> 
>> I don't really have any skin in the game since this is a Unix specific 
>> issue (i.e., the "squeakvm" dependency) that doesn't really apply on Mac 
>> or Windows. That said, I'll add my $.02 by saying that in our Linux 
>> production systems we do exactly what you were proposing, i.e., we have 
>> fallback VMs installed side-by-side with the latest and symlink the 
>> desired VM. That makes it very easy to switch the default *and* allows 
>> you to be explicit where you want to (i.e., by executing from the 
>> linked-to location).
>> 
> 
> Well that is Bert's suggestion exactly, and it is consistent with John's
> point of view as well, so it sounds like this is the right thing to do.
> 
> Dave

So we would ship two VMs. One is the old interpreter. The other is cog, or the stack interpreter, depending on the machine's architecture.

The two new ones should be in one source archive, IMHO. At build time either cog or stack VM would be selected depending on the machine's architecture. What should the name be for those binaries? Just use "squeakvm-cog" even if it's the Stack VM because it can run the same images?

Would we drop development on the old interpreter? If plugins were compatible between it and the newer VMs (are they?) it should not be much effort to keep it alive.

What about 64 bit images? We don't need extra sources for those VMs, since it's just a build flag. But we need a naming scheme for these too.

- Bert -