On Wed, Jul 24, 2013 at 08:22:42AM +0100, Frank Shearar wrote:
> Hi David,
> 
> I just noticed/realised that now that we have multiple build slaves
> (thanks Tony!), we have a problem in that the CogVM build will fail on
> lfpdeb64/lfpdeb32 because those slaves don't have the makevm script.
> 
> What's a good way to fix this?
> 

Hi Frank,

I will take a look and see what's going on, though it might be a day
or two before I can get to it. The makevm script(s) are in the project
workspaces of course, and I've been keeping them versioned (RCS) in my
home directory on build.squeak.org. I guess this means I need to figure
out how to save them with git like you have done with the other projects
(sorry I have not really used git before, so I'll have to give it a try).

That said, I would like to make it clear that the intent of the InterpreterVM
and CogVM jobs on build.squeak.org is *not* to produce compiled VMs. Rather
they are intended to produce source tarballs from the original Smalltalk source
(VMMaker and other pieces) along with latest platform sources. The compilation
step in those jobs is performed in order to verify that the generated sources
are compilable, since at various times this may not be the case.

I tried to make this clear in the project descriptions for InterpreterVM:

  "Update to bleeding edge VM platforms sources and VMMaker Smalltalk code.
   Generate C code for interpreter VM. Configure and build on this machine
   to verify source integrity. Create a tarball of sources for a Unix
   interpreter VM suitable for building on a Unix/Linux machine."

   Official releases of source tarballs and compiled Squeak VMs for Unix
   are at http://squeakvm.org/unix/."

And for CogVM:

  "Update to bleeding edge oscog VM platforms sources and oscog VMMaker
   Smalltalk code. Generate C code for Cog VM. Configure and build on
   this machine to verify source integrity. Create a tarball of sources
   for a Unix Cog VM suitable for building on a Unix/Linux machine. 

   Official releases of Cog VMs and sources are at
   http://www.mirandabanda.org/files/Cog/VM/. 

   See http://www.mirandabanda.org/cogblog/ for additional information
   about Cog."


There might be some value in maintaining automated builds of the latest
VM sources, and if so we should definitely work this out with the authors
and maintainers of the VMs. The key people right now are Ian Piumarta
(author of the Unix VM and host of the squeakvm.org site that has served
the VM community for many years), and Eliot Miranda, creator of Cog.

I'm saying this because I do not want VMs on our build.squeak.org
server to be perceived as official or supported VMs. Just as an example
of why this could cause problems, if you were to take a compiled VM from
the CogVM project on build.squeak.org and install it on your own computer
at home, it would not work (because of the way that I specified the install
directory in the build script). That would inevitably result in questions
to Eliot that would waste his time and try his patience. Likewise for the
standard Unix VM, if someone takes a compiled VM from build.squeak.org,
it might work but if there is a problem there is no way that Ian can
help, and it's a waste of his time if we create problems like that.

> (Also, I'm guessing that the CogVM build should be limited to a 32 bit
> machine and, if we want to test its 64-bit-fitness, that we run a
> separate job (again limited, but to a 64 bit machine))

It depends on the intent of the job that you are setting up. If the
intent is to see if you can successfully compile the VM, then there is
nothing wrong with building a 32-bit Cog VM on a 64-bit machine, as
long as the compiler options are set up right and the necessary 32-bit
libraries are installed. Aside from that it should make no difference.

On the other hand, if the intent is to test whether a compiled VM (such
as a binary release from squeakvm.org or mirandabanda.org) will run on
some target 32-bit or 64-bit machine, then yes you would definitely want
to set up different jobs for that. We may need quite a lot of build
slaves to test the various permutations of OS and CPU, but it might be
a really useful thing if that could be done :)

Dave