On 24 July 2013 16:34, David T. Lewis <lewis at mail.msen.com> wrote:
> 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).

I'm happy to help out. If the makevm stuff was in a git repository, we
could take a brand new slave and say "check out this repository, and
run this file". Well, it doesn't have to be a git repository. It's
just that github is so convenient!

> 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.

While I fully understand the nature of the InterpreterVM and CogVM
jobs, it's certainly worthwhile repeating this so that people don't
get the wrong idea.

> 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.

Totally. I _would_ like _vm devs_ to use the bleeding edge VMs. Or,
rather, I would be very happy to supply CI support to the VM guys, if
it's useful to them. For instance, I can see value in running the full
suite of image tests on a cutting edge VM.

>> (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.

OK, that's good.

> 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 :)

Agreed!

frank

> Dave
>
>